possible bug with "M66 P26 L4 Q7"? or my use of it? or with FlexGUI?

More
2 years 3 weeks ago #311245 by travis036
whole config: github.com/travis-farmer/linuxcnc
my routine using it: github.com/travis-farmer/linuxcnc/blob/m...files/toolchange.ngc
(line 11)

the signal sits at LOW, but when the spindle VFD is running or braking, it goes HIGH, and falls back to LOW after the spindle stops.

what i experienced is a program hang when the routine is started with a spinning spindle, but even when the spindle completes the stop, the program then continues, but aborts for some reason, while it is probing down.

what i observed with the GUI (FlexGUI by JT) is that when M66 starts, the GUI hangs, even after the M66 passes with success. i know it hangs because i watch the hal-pin on the GUI, and it doesn't change for the signal in question (motion.digital-in-26). but as soon as it does, the tool-setter probing operation (remapped as M201) aborts.

if i change the line to "M66 P26 L2 Q7", it hangs the GUI and operations permanently, if the spindle is not turning.

what is going wrong here? is it my error? the GUI error, or a LinuxCNC error? my errors are easier to fix...
 

Please Log in to join the conversation.

More
2 years 3 weeks ago #311246 by travis036
would i be better with:
Code:
M66 P26 L0     o400 if[#5399 NE 0]         M66 P26 L2 Q7         o215 if [#5399 EQ -1]             M5             (msg,Warning, spindle brake not active! PAUSED)             M0         o215 endif     o400 endif so it exits immediately if not turning, and waits for a fall event if it is turning?

Please Log in to join the conversation.

More
2 years 3 weeks ago #311249 by travis036
changed to the version in my reply, now heading out to test... expecting failure... hope nothing breaks...

Please Log in to join the conversation.

More
2 years 3 weeks ago #311251 by travis036
no joy.
even changing the polarity of the pin and using "M66 P26 L1 Q10" fails to work

Please Log in to join the conversation.

More
2 years 3 weeks ago #311254 by travis036
i suspect if i am reading the hal pin with FlexGUI and with a M66, it may be the cause of the hang. reaching here, as i can't find any other cause...
will continue testing tomorrow...

Please Log in to join the conversation.

More
2 years 3 weeks ago #311287 by travis036
ok, my issue was a FlexGUI bug, somewhere. i confirmed by testing again with flex to make sure no changes. then i switched GUIs to Axis and performed the same test, only in Axis everything worked as it was supposed to.

my tool changer routine contains a M66 line. with the digital pin in the M66 cleared (spindle not running), the routine works fine. i issue a "T1 M6", and it changes tools and probes the tool and returns to resting position.
with the digital pin not cleared (spindle running), i issue a "T1 M6", and it stops the spindle, waits for it to stop (GUI Hangs), then changes and starts probing but aborts when the GUI stops hanging.

again, under Axis, this is not an issue, as to say it all works as it is supposed to.

i used Hal Show to view the pin status while in FlexGUI, and the pin changes when it is supposed to, without hang. it is the GUI hanging during a M66 wait.

Please Log in to join the conversation.

More
2 years 3 weeks ago #311420 by travis036
issue has been identified, i believe, within FlexGUI, and an issue generated on that Git.

part of my problem was i was running incompatible operations. i was using MDI buttons to simulate auto operations. so i instead hand-wrote a crude Gcode program that selected a tool, started the spindle, did some moves with it. selected another tool, did some moves with that. and again, selected a third tool, and did some more moves. then stopped the spindle and ended program.
in case anybody is interested in how crude the code was: github.com/travis-farmer/linuxcnc/blob/m...r/gcode/atc-test.ngc i don't suggest running it, unless you have the clearance to do so...

what i found, is that both Axis and FlexGUI ran the program flawlessly... that is to say it did exactly as coded, but not exactly as i wanted...
there was no hang of the GUI, so my theory that it has to do with the python c.wait_complete() hanging the code, is probably correct. but will it interfere with my normal operations? not if i do them as intended.

the real issue being that my routine took longer than the c.wait_complete() timout, and the GUI aborted the routine.

so long story longer, i made my recomendations to JT in the Git issue, based on my suspicions, research, and new tests.

Please Log in to join the conversation.

Time to create page: 0.109 seconds
Powered by Kunena Forum