JuKu

> The deceleration should be actually starting when the switch transition occurs. Please let me know if you see evidence to the contrary – that would be a bug.

Unfortunately, I do see the contrary. These are the settings:

$z
[zam] z axis mode                 1 [standard]
[zvm] z velocity maximum       1000.000 mm/min
[zfr] z feedrate maximum       1000.000 mm/min
[ztm] z travel maximum           80.000 mm
[zjm] z jerk maximum           2000 mm/min^3 * 1 million
[zjh] z jerk homing            5000 mm/min^3 * 1 million
[zjd] z junction deviation        0.0100 mm (larger is faster)
[zsn] z switch min                3 [0=off,1=homing,2=limit,3=limit+homing]
[zsx] z switch max                2 [0=off,1=homing,2=limit,3=limit+homing]
[zsv] z search velocity        1000.000 mm/min
[zlv] z latch velocity         1000.000 mm/min
[zlb] z latch backoff            25.000 mm
[zzb] z zero backoff              0.000 mm
tinyg [mm] ok>
tinyg [mm] ok>
$3
[3ma] m3 map to axis              2 [0=X,1=Y,2=Z...]
[3sa] m3 step angle               1.800 deg
[3tr] m3 travel per revolution    8.000 mm
[3mi] m3 microsteps               2 [1,2,4,8]
[3po] m3 polarity                 1 [0=normal,1=reverse]
[3pm] m3 power management         0 [0=remain powered,1=power down when idle]
tinyg [mm] ok>

Note the long zlb value. On homing, the z travels all 25mm, even though it certainly has enough time to stop. On slower zlv settings, it does stop right after the switch clears. I tried on other axis which have different settings, but their behaviour on my machine is as you say.

Btw, I was NOT correct about the latch backoff functionality. I thought the machine would start from the “bottom” of the switch and always back off the specified amount (like my z behaves now). I think I get it now, and I need to change my settings – or maybe not, I actually like the current behaviour. Fast settings produce good clearing for the switches (although not as you intended) and the homing is swift.

And if I may phrase it a bit differently, this is how I now understand homing operation (please correct me if this is (still) not right): When the homing cycle has stopped at the “bottom” of the travel, it starts backing away at the specified speed*. When the switch clears, the machine has picked up some speed, but it stops when it can*. The resulting end position has nothing to do with latch backoff value, but is a function of the speed and jerk settings.

(*: Latch velocity and jerk homing values are used)

• This reply was modified 11 years ago by JuKu.
• This reply was modified 11 years ago by JuKu.
• This reply was modified 11 years ago by JuKu. Reason: spelling is hard

I played with it some more this morning. I found that:

– Jerk setting has a noticeable effect to where it stops – as expected. When using the fast end of the machine, speed also has an effect. So, when I got different stopping positions at speeds 1000 and 2000, nothing is wrong.

– At slow latch and search velocities, it does not obey the latch backup setting, but stops as soon as the switch is cleared. This I think is the real issue.

My 1/3 – 2/3 results at speeds 500 was likely the “right-at-the-limit” setting for yesterday’s star positions. Today, I didn’t get any random results, the machine stopped either at the switch or the specified backup position.

Workaround: Don’t be ridiculously slow. 🙂 So, while you do want to fix this, it is not urgent for me.

• This reply was modified 11 years ago by JuKu.

Yes, I do multithread also. 🙂 But I am also doing optical alignment, and for that to work, I need to be sure the machine is not moving and the position information is updated before taking a look.

Answering my own question to share my experiences during last two days: As said, the goal is to recognize TinyG idle state, where all status variables are up to date and the machine state or position will not change anymore. The following logic seems to work for my application:

In the controlling software:
– Filter movement commands beforehand, so that commands that don’t result in movement, are not sent to TinyG.
-Home one axis at a time.

In the TinyG interface setion, my communication is set up so that only full lines get processed. The line iterpretation routine logic is:

-If homing for axis q (where q is x, y or z; I don’t have homing on other axis), wait for a line that has both “mpoq”:0.000 and “coor”:2 => handle it as a status report (update all status variables), fire ready event and return.

-If line starts with {“sr”: => handle it as a status report. If it also contains “stat”:3 , fire ready event. Return.

-If line starts with {“r”:{“sr” , it is the response for asking a status report => Remove the wrapper, handle line as a status report, fire ready event and return

-If line starts with {“r”: , it is a response for asking or setting a setting or setting group => replace all “n” (where n = 1, 2, 3 or 4) with “motor_n” to get valid field names for Microsoft JavaScriptSerializer class (and other JSON interpretes, I suppose). Handle line as a settings report (updating UI where applicable etc), fire ready event and return.

—
The issues that caused some thinking were ‘no movement’ commands (that send out an empty status report) and a bug(?) in homing routine: On X axis homing, the stat:3 report comes the second to last status report, not the last. Firmware is 392.65, btw.

Apparently it was noise on my switch lines. Even though I have shielded motor lines and shielded switch lines ans everything is properly grounded, filtering the switch input helped.

For the record, I put 100R in series with the switch line and 100n capacitors to ground after the 100R. This cured the noise issue. The extra protection does not hurt either. (You might want to add a note to the wiki snd maybe, if there ever is going to be v8…)