yes, mesaflash still says 5i25 not found

 

Did you try running mesaflash after running LinuxCNC?
 

The problem isn't the 50ms, it's that during that time the machine is *moving*. I.e. where you home depends on the bouncing of the sensor, which means it's unpredictable, which means every other position is also unreliable.
If you "hit" on the first contact, instead of waiting for the physics to settle down, you get a more predictable "moment" when the machine is in the known state.
You'd think it wouldn't matter, but I've seen my probe go measurably past the right spot before it "hits", and my probing routines actually probe in both directions (G38.2 then G38.4, and take the average) to try to eliminate this overshoot.
With a "first hit" debouncer, you could set the debounce time to 3 seconds and still get the right value.

I don't see a problem with de-bouncing a signal when homing since the purpose of homing is to put the machine in a known state and stop before doing anything else. If that takes an extra 50ms to insure the starting position of all axes, it is a non sequitur since the result is the machine is stopped. It might be a minor issues when hitting a limit switch while machining, but I'd rather error on fact rather than bounce.

Just my two cents worth.

This may not help but this 2017 post shows how to update a gmoccappy screen handler from gcode which sounds like your problem 1
forum.linuxcnc.org/plasma-laser/32691-settings-from-g-code-file
Here different values are set using an analog input which is decoded and used to modify screen elements. eg 900 and 999 change screen settings.

kind of weird that i can see it talking to a 5i25 in the error file

still cant seem to find the board 

Yes, you need to install firmware that matches the 7I77

You first need to download the 5i25.zip from

  www.mesanet.com/software/parallel/5i25.zip

unzip and then change to the configs/hostmot2 directory and then

sudo mesaflash --device 5i25 --write 5i25_7i77x2.bit --reload


 

Sigh, my brain couldn't help but try to fix this. My idea: change debounce() to act like this:

state in out action
neg 0 x state = -delay
neg 1 x state ++
zero 0 1 out=1 state = delay
zero 1 0 out=0 state = -delay
pos 1 x state = delay
pos 0 x state --

(if out isn't persistent, use state == +1 or -1 instead of zero)

     Hi all;I was having this error randomly pop-up while running my level-check routine. Searching the forum I found  Billiiles  response to seuchato's post on a similar topic and applied his suggestion to add some dwell to insure the machine was stable before the next move statement, but I'm still getting random errors during the routine. The routine I wrote uses a touch plate made from 1/8 aluminum plate offset from the table by 5 cabinet bumpers, one in each corner and one in the middle. (See attached picture).I had used this routine and plate extensively without issues prior to a major rebuild of my machine to add a second Y axis to eliminate racking and a 2 DOF gimble to square the Z axis to the table. With all of that retrofitting completed over the winter I'm finally back to leveling the table. Now I'm having issues with the routine. In addition, I've verified that there is a open between the plate and the table using an Ohm meter on the 2 ohm setting while there is .2-.3 ohms resistance between the touch plate and the point where the touch plate cable plugs into its receptacle on the front of the bench.  Connection is made with a banana plug and socket. I've attached my code for your review. I'm probably missing something obvious (forest and the trees syndrome).  Any suggestions would be greatly appreciated.

Kind Regards,

I have to add debounce to my sensors, too, and I don't like doing it. I tried using probing moves to move "away" from the sensors, but that's too complicated. The problem with debounce.N is that it delays the signal (it's a low pass filter). Perhaps we need a different kind of debounce? Something that reacts immediately to the first edge, then ignores further edges for a while? That would trigger on the first hit, then ignore the bouncing, trigger on the first release, then ignore that bouncing, etc. That would make probing and non-probing moves more predictable without delaying anything.