Feature/Clarity request: checkEndstops() in both PrintLine and DeltaSegment class

[kyrreaa]

I am trying to add the new piezo bed-sensor support and it requires some specialy changes/mods for the way it reads the endstops. I then notice that the checkEndstops() is being called from many places. Would it not be enough to update a volatile value and read this all other places than in the step routine which should check the endstops and z probe on every step?

The reason I ask is the piezo sensor circuit is a latching circuit to avoid missing any pulses (since piezo sensors are ac not dc capable like a switch is), and has to be reset by the controller after every triggered signal is read. It also means one cannot back off untill it releases again, but have to back off a set or assumed ammount. The latter is easy to fix if need be, but the former seems a bit messy at the moment.

The G31 command etc can be easily fixed by making them check if a move is currently in progress and if so report the probe hit variable (which I thought about introducing) but read the probe directly if not. It's a tad fiddly but it could work well.

[repetier]

All checks return the current status independently of any moves. That way it is e.g. possible to test switches by hand.

I understand your special problem, but storing the result only on moves and store it in a variant would make it less functional and slower for the rest of the world.

The good thing is that all the tests get only called once per motion step before the next step is done, so you can simply read it and reset it at the end of checkEndstops. You loose G31 and M119 but for the real moves it should keep working as expected.

[kyrreaa]

The point is to roll this out to any person building deltas as it reduces cost of printer by around $30. I am still working on it though. What I was mostly puzzled by was the existance of a duplicate function both in printline and in deltasegment but I guess this is due to the deltas needing extra splits. However, both appear to be compiled which I do not understand.

I am still working on the electronic interface though, as piezos act differently from FSRs.

BTW: Since display updates and such also use endstop into etc, atleast in new mods/updates it is another reason not to use the slow read command for the pin. Since it is natural to assume it can change after every step it would actually be faster to store it in one routine when stepping and access it as a bool from other code. Reading from pin is a load mask, read pin register, mask data-operation before a jump on flag while reading a bool is a "load bool" and jump on flag operation. In theory half the cycles. In addition it requires one less register which means it would also run better in a ISR, especially if the ISR already uses few or no regs. Anyway, checking a bool is faster than checking a pin. Always.