Algodoo

If you make the ball small and dense (radius=0.05, density=1000.0) and use the Large Amplitude Pendulum formula then g comes close to the expected value. I used a 3m long remote hinge pendulum with radius=0.05, density=1000.0, and starting angle=15° and calculated g to be 9.799 m/s^2.

Here are some ideas:
1. Use a stiff spring for the pendulum string. A spring should add no mass.
2. Attach the spring to the center of the bob.
3. Make the bob small and dense.
4. Decrease the size of the initial angle or use the large angle formula.
5. Glue a large low density bob to the small one.

Sure your scene might not look as good, but at least you will get accurate results.

Your first scene got within 1.6% of g in 52 seconds. This scene gets within 1.2% in 158 seconds. That's a high price to pay for a 27% error reduction. I've attached a scene that gets within 0.05% in 5 seconds. That's a 97% error reduction with respect to your first scene. Use the concept or code if you like (or not). You scenes look good and are engaging and when you get down to it, less than 2% error isn't too bad for a lab experiment. Don't let my obsessiveness dampen your spirits. I'm just trying to help.

P.S. Here's a suggestion. Delete this scene and attach a small heavy (r=0.01m, density = 100,000) circle to the middle of the pendulum bob in your original scene. This will result in g=9.73m/s^2 which is only a 0.7% error. Maybe calculate and show the error in your scene.

Q: How would those rods be attached without a cutaway surface in an actual (real life) gimbal assembly?
A: There could be (2) holes or a slot thru the slider body above the nuts. The nuts would have tapped holes in at least one of the facets. Standoffs would be screwed into the nuts and extend beyond the top surface of the slider. A small connecting rod or wire would connect the end of the standoffs to the slider body.

Nice work.

P.S. I made a response scene to your scene. It is not meant to be a suggestion or criticism. I made the scene because that's what I had on my brain after playing with your scene.

Don't believe everything I say. This scene is how I might make a positioning slide. I don't know how they are typically made, but I suspect you would want them to have zero free play, be not over-constrained, and to accommodate slight variations in nut centering and perpendicularity. An example of over-constraint is a slider with (2) rods and (4) close fitting bushings. If the rod parallelism varies more than the bushing clearance, then there is high friction. If (2) bushings on one rod are close fitting and the (2) on the other rod have elongated holes (slots) so they act like guide forks, then the original over-constraint is eliminated.

Thanks.

Thanks. I'm hoping to catch some users with the fake Script widget.

Suggestions:
1. Increase the contrast between the start button triangle and button background.
2. Also show the velocity in m/s since that is what's used in the formula. You could show it like this: 20 km/hr (5.56 m/s).

Interesting mechanism. Good tutorial. One suggestion: replace the word "square" with "box" or "rectangle" in your tutorial.

Nice work.

You need to understand a subject before trying to teach others. The Motor HP=2*PI*N*T makes no sense to me. Please provide an example on how this works.

This is my understanding:
RPM = angvel * 60.0 / (2.0 * math.pi) Units:(rad/sec)*(sec/min)/(rad/rev)=rev/min
powerI­nWatts = torqueInNm * angvel
powerInHP = powerInWatts/745.7
motorCurrent = powerInWatts/motorVoltage

Other stuff:
Setting glued to true or false doesn't do anything. Delete that code. It's confusing.
Somebody correct me if I'm wrong but "e.this." is not required in any of your code.
Not every variable needs to be a "scene.my." variable:
someVariable := 123 is seen within the procedure
_someVariable := 123 is seen within the object and needs to be entered in the upper left hand text box of the Script widget before use.
scene.my.someVariable := 123 is seen by all objects
":=" is used to initialize a variable, "=" is used after initialization

P.S. See comments in Inteligent Frog for an example.

This is a good scene with nothing really wrong with it, but I'm going to pick on the code anyway in order to show an example of variable initialization and scope. The following refers to the postStep code in the frog. The present code has (11) "e.this.", (52) "scene.my.", and (0) ":=". The revised code has (0) "e.this.", (17) "scene.my.", and (9) ":=".

To change the code, enter the following in the upper left hand text box of the frog Script widget:
_jumpdelaytime := 0.0;
_frogvel := 0.0;
_randint := (min, max)=>{
min + math.toInt(rand.uniform01 * (max - min))
};

Then change the postStep code to:
(e)=>{
angle >= math.pi * 0.1 ? {
angle = math.pi * 0.1
} : {};
angle <= - math.pi * 0.1 ? {
angle = - math.pi * 0.1
} : {};
frogpos := pos - [0, size(1) / 2];
targetdistance := ((scene.my.targetpos(1) - frogpos(1)) ^ 2 + (scene.my.targetpos(0) - frogpos(0)) ^ 2) ^ 0.5;
targetangle := math.atan((scene.my.targetpos(1) - frogpos(1)) / (scene.my.targetpos(0) - frogpos(0)));
scene.my.playbutton == 1 ? {
_jumpdelaytime = sim.time;
scene.my.stonehit = 0
} : {};
sim.time >= _jumpdelaytime + 0.01 && sim.time <= _jumpdelaytime + 0.02 ? {
vel = _frogvel;
angle = - 0.05
} : {};
mousedistance := ((app.mousepos(0) - pos(0)) ^ 2 + (app.mousepos(1) - pos(1)) ^ 2) ^ 0.5;
mouseangle := math.atan((app.mousepos(1) - frogpos(1)) / (app.mousepos(0) - frogpos(1)));
heightdiff := scene.my.targetpos(1) - frogpos(1);
horidiff := scene.my.targetpos(0) - frogpos(0);
jumpangle := math.atan((heightdiff + targetdistance) / horidiff);
jumpvectorvel := (sim.gravitystrength * (heightdiff + targetdistance)) ^ 0.5;
scene.my.mode == 1 ? {
_frogvel = [jumpvectorvel * math.cos(jumpangle), jumpvectorvel * math.sin(jumpangle)]
} : {
_frogvel = [scene.my.inputvelocity * math.cos(scene.my.inputangle * math.pi / 180), scene.my.inputvelocity * math.sin(scene.my.inputangle * math.pi / 180)]
};
sim.time >= scene.my.spawndelay + 1.0 && sim.time <= scene.my.spawndelay + 1.005 && scene.my.stonehit == 1 ? {
pos = [_randint(1, 46), 1.0];
scene.my.stonepos = [_randint(56, 63), _randint(3, 24)]
} : {}
}

The meter values for this scene are not what I would expect. Algodoo calculates to 7 decimal places yet the motor and drum RPM are off 5%, Amps are off 22%, Power and HP are off 8%.

Paste the following postStep code in a box in your scene to see the expected values.

(e)=>{
P := scene.my.motorangvel * scene.my.torque;
HP := P / 745.7;
RPM := scene.my.motorangvel * 60.0 / (2.0 * math.pi);
Amps := P / 415.0;
DrumRPM := scene.my.drumangvel * 60 / (2.0 * math.pi);
s := "";
s = s + "angVel: " + scene.my.motorangvel + "\
";
s = s + "torque: " + scene.my.torque + "\
";
s = s + "RPM: " + RPM + "\
";
s = s + "Power: " + P + "\
";
s = s + "HP: " + HP + "\
";
s = s + "Amps: " + Amps + "\
";
s = s + "DrumRPM: " + DrumRPM;
text = s
}

I've added a response scene showing the basics.

Q: How can the "motor efficiency" equal and exceed 100 percent by applying braking force?
A: Ask Emil. The motor doesn't completely stop when braking torque is greater than motor torque. In real life the motor would stop and the motor efficiency would drop to zero.

Looking good.

Very well done concept, presentation, and coding.
⭐⭐⭐⭐⭐

It all seemed to make sense except for the storage of 85000 pounds of human aboard the spacecraft then I realized the humans must be freeze dried.

.... . .-.. .--. / .- .-.. .. . -. ...

I find the slide rule easier to use with standard zooming as opposed to being limited to (2) fixed zoom values. Someone once said to me "whenever software does something for you it does something to you".

Thanks. Making the scene was harder than I originally thought. I'm impressed with your decoding ability. I can only decode "HELLO WORLD" so far, since that's what I used for testing.

I still have (2) issues with this scene:
1. The slider is not the same scale as the fixed portion. The slider textureMatrix should be [0.006571155, 0.0, 0.5, 0.0, 0.1431, 0.5, 0.0, 0.0, 1.0]
2. I can't pan up and down when running the scene.

P.S. I see part of the problem is that the original image has some distortion.

For Reference:
Simulated Pickett N909-ES Slide Rule
How To Use The Slide Rule

Very interesting device from a physics and engineering perspective. My understanding is that it is an automatic dot generator. Thanks for the info, but I don't plan on Algodooing the Vibroplex Bug anytime soon.

_DIST = math.vec.dist(scene.my.pos1,scene.my.pos2)

Looking good.

Very interesting. Now tell us how you did that.

for(string.length(circle), (i)=>{
should be
for(string.length(_circle), (i)=>{

I made a response scene to this scene. If you don't like me messing with your scene, then let me know and I will remove the response scene.

Thanks. I have not heard of that or tried that b4.

I see that you, Xray, and I are all old timers.

P.S. I see that you are a Mechanical Engineer. Check out Algodoo for Engineering.

Q: Where does it say I'm an M.E?
A: Nowhere. I was responding to vinodrai. Are you making a joke because the response is open to interpretation?

Q: All I see on that page are technical engineering type scenes that were made by YOU.
A: Yes. I can see that I am very popular on that web site.