So from memory (I'm at work) Read_inputs always sends a status update the first time though because the estop HAL pin is initialized false but needs to be true (estop state). The forces a status command send that requires the command serial number to be +1
Because the serial number is incremented before the check for tool_init ..that check always fails. I agree removing the +1 makes the tool_init be called. I feel it smells bad to remove it..the comments say its required. If you set print statements for command serial number and serial echo number they dont jive very well but seem to even out after a while. I dont understand how the system is supposed to work reliable yet. I will document what I can the the developers docs...I actually think this should be encouraged more.... So it seems: Multiple commands sent to iocontrol ..the last one wins. Sending a status update out can drop the command coming in because they both use the same serial number to mark them as acted on. If we have a io_init case statement..it should get called or we should incorporate io_init with tool_int...there seems to be no hint of the design or requirements ... so I guess we should do that. Also Io control manipulates tool info stuff that I think should be done else where.... iocontrol should just do iocontrol. In short I wish to figure out requirements and a reliable design to follow...let's not patch it to work. Maybe others have some thoughts? I beleive others were working on tool changing code. My thoughts for today anyways. Thanks Chris M -------- Original message -------- From: andy pugh <[email protected]> Date: 2019-04-29 3:45 p.m. (GMT-07:00) To: EMC developers <[email protected]> Subject: Re: [Emc-developers] iocontrol.cc never runs EMC_TOOL_INIT message On Thu, 18 Apr 2019 at 04:34, Chris Morley <[email protected]> wrote: > > While I was toying with a tool startup problem from the forum, I discovered > that iocontrol.cc never runs > the EMC_TOOL_INIT NML message even though taskclass.cc sends it. EMC_TOOOL_INIT seems to load the tool table, but that is already done outside the loop. (Possibly because the tool init message was always being ignored...) Compare: https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/iotask/ioControl.cc#L699 https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/iotask/ioControl.cc#L771 > unfortunately just before that when checking halpins for changes the > echo_serial_number is advanced, I guess to sent the pin changes to status. If you remove the "+ 1" from https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/iotask/ioControl.cc#L726 then as far as I can see everything works just the same, except that now EMC_TOOL_INIT does now run. The HAL pins updated in iocontrol / read_hal_inputs() are emc-enable in (important) and lube-level (which I think we recently decided does nothing at all, and never has) E-stop appears to work if the "+ 1" is removed so I think that might be a bug. Note that read_tool_inputs() does _not_ add the +1, yet appears otherwise identical. I can't help feeling that we should remove the +1 and put all the too init stuff in EMC_TOOL_INIT. But on the other hand, it is all working as it is.... -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1916 _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
