Hi,
a few questions there....but I think several of them are related.
It seems to me that Mach only registers the limit/home signals as a courtesy and relies on the ESS to stop motion or home an axis
That is how Mach is supposed to work.
A Windows PC is not, nor ever will be, a realtime system, that is to say it cannot respond within microseconds to a home or
limit switch event say. Yet a CNC controller must absolutely be a realtime controller.
Mach (3 or 4), in fact any Windows based CNC software MUST be a buffered control system. Thus all movement instructions
issue by Machs trajectory planner get handed to the motion controller in a buffer, typically 20-100 ms worth.
The motion controller must however be a realtime device.
Art Fennerty wrote Machs original parallel port driver which made the PC's CPU perform in a near realtime fashion.
The PC programming world was astounded.....to my knowledge no one has been able to replicate his work. It was a direct
consequence of the (free) parallel port (quasi realtime) that allowed Mach3 to attain such a wide following.
Just as a matter of interest LinuxCNC IS a realtime system and that comes about because of R(eal)T(ime)E(xtensions) which
is applicable to certain Linux Distros. As a consequence LinuxCNC is not a buffered system.
Advance a decade and now Mach4 is native to and effectively requires an external motion controller. Such a controller
must handle all realtime functions. Some of which you are asking about, in particular, home and limit events. If the ESS
detects a limit event it should shut down all Step/Dir signals immediately, or within a few microseconds. If however the
ESS reports to Mach and then Mach issues an instruction to the ESS to stop all motion then the communication delays
(because of buffering) are tens of milliseconds, way too slow to be considered realtime.
When approaching my limit switches, some of the time when the switch is triggered I get a message in Mach 4 that says something to the effect of "ESS: Motor 0++ Limit triggered" and all axes become disabled. This is fast and very repeatable in position even when jogging at a good clip
This is indeed an example where the ESS is responding in realtime (less than 20usec or so). The giveaway is the report
beginning with 'ESS:Motor0............'.
Other times I get a message (from Mach I think) that says something like "X++ limit Active". It reacts very slowly and does not disable the axes or stop jogging (it does allow me to crash the machine).
This on the other hand sounds like Mach is in control and the communication delays both from the ESS to Mach and then
back again, from Mach to the ESS, are mounting up to allow a crash.
This suggests to me that you have certain events controlled by a Lua script (subject to comm delays) and certain other functions
which are (rightly) handled by the ESS in realtime.
The giveaway is your comment about 'X++ Limit Active' yet not causing an Estop. Mach does not automatically cause an Estop
if a limit is triggered, you have to program that behavior if that is what you wish.
In many industrial situations you cannot just program an Estop because you need to sequence a shutdown, something like
applying the brake so a heavy Z axis does not fall down and crush your operator.
When exiting the "Configure" -> "Control" menu, two general purpose outputs energize for a brief moment (regardless of machine state).
I suspect that comes about because the machine is disabled the outputs are going to their natural state, that is pulled high
(or pulled low) by your controller or BoB. Once Mach assumes control then the outputs assume their correct state, it just
in that brief moment when they are uncontrolled that results in a problem.
The only thing I can suggest is that you try reversing the sense of the signal. That would require an additional invert operation,
may be a relay, at or near the output. The only other way would to analyse the natural (pull up/ pull down) state of the pins
and reverse that sense.
Craig
Guest
