Advanced Search

I am, which IRC are you referring to? I'll join up!

edit: oops, found it! on the community page of linuxcnc

Hi there,

I'm setting up some surface grinder automation for some use cases where calling subroutines isn't quite dynamic enough (hal parameters change mid-job ), so being able to override things with my own python has been immensely helpful! I have discovered a problem unrelated to that though, this is reproduceable without importing any python. It happens when loading a custom hal module and the module, unaware of flexgui, issues MDI commands.

I am running multiple MDI commands in a different process that is triggered by HAL pins. Flexgui is switching the hal state in order to manage the background process. That part is working great.

It seems that flexgui has some code that watches the interp state, and if an MDI command is done, switches the task state back into MANUAL. My first command sets it into MDI mode, executes one MDI command, executes a second, waits until it's complete, and then the loop restarts. By the time the second loop iteration starts setting the MDI mode, it seems that flexgui is attempting to switch the mode from MDI back to Manual. Even if I switch it to MDI again before each MDI command, flexgui has switched it back to manual before my next MDI command can run. Future loop iterations, even though they switch to MDI mode at the beginning of the loop, don't stay in MDI mode before the next line runs.

This doesn't occur for any MDI commands sent via the UI thread, I assume because it's happening within the same update frame as flex is running in, so everything happens sequentially. That or the race condition has a longer time interval, so less of a chance for it to happen. It's very easy to make it happen when there are multiple processes or threads however.

I've narrowed it down to these lines in the below commit, removing it makes this all work, and preserves the functioning of the MDI tab along with it's history, but I'm not sure what implications this might have on anything else that flexgui is doing with it.
github.com/digiexchris/flexgui/commit/9f...d882032d85a41f7968d3

A minimal reproducable example would be this:
github.com/digiexchris/qtpyvcp_grinder_t...der_touch/process.py
and place the following at the end of your main hal file:
loadusr python3 process.py

It will delay the loop by 10 seconds in order for you to clear estop, set the machine to on, and home it.

Then the console you started linuxcnc in should start to give you the following output, and does using Touchy and Axis:

Loop
Current mode: Manual
Current mode: MDI
Current mode: MDI
Current mode: MDI
Loop
Current mode: MDI
Current mode: MDI
Current mode: MDI
Current mode: MDI
Loop
Current mode: MDI
Current mode: MDI
Current mode: MDI
Current mode: MDI
Loop
Current mode: MDI
Current mode: MDI
Current mode: MDI
Current mode: MDI
Loop
Current mode: MDI
Current mode: MDI
Current mode: MDI

and you can watch the X coordinate in the UI oscillate between X1 X2. 

In Flex, 

Loop
Current mode: Manual
Current mode: Manual
Must be in MDI mode to issue MDI command
Current mode: Manual
Must be in MDI mode to issue MDI command
Current mode: Manual
Loop
Current mode: Manual
Current mode: Manual
Must be in MDI mode to issue MDI command
Current mode: Manual
Must be in MDI mode to issue MDI command
Current mode: Manual
Loop
Current mode: Manual
Current mode: Manual
Must be in MDI mode to issue MDI command
Current mode: Manual
Must be in MDI mode to issue MDI command
Current mode: Manual

Occasionally you do see it go into MDI for one iteration, but flex is usually pulling it into manual pretty quickly. For some reason, When I control the loop with a HAL pin, which is changed by flexgui, the first iteration of the loop works, and subsequent ones fail with the above reasoning. But I suspect that's just a side effect of the GSTAT polling and handlers slowing the UI thread down enough for the first loop iteration to work.
 
Any suggestions? Auto mode doesn't work because I can't have the interpreter load the entire gcode program from the start, it's generated as the job progresses, kinda like how gcode is streamed to a 3d printer. Ideally I'd prefer if this behaviour matched Axis and Touchy (who have intentionally maintained the ability to execute multiple MDI commands sequentially with one mode switch)

Hi Aciera,

Thank you for the response and sorry again for the delay.  

I am glad to hear that motion.adaptive-feed is available and useful for what I am trying to do.  I have a couple questions. First, and more basically, how do I turn on motion.adaptive-feed? I found some info on the "motion" page, but it doesn't seem to show how to manipulate it.  Is it on the .ini file? 

Second, and more specifically, how would I get the machine to move backwards, but only when it is sensing a short.  There is an output from the EDM power supply that goes either high or low (I am not sure which) when the supply senses a short. Probably what I want is when a short is detected for the machine to move back a specific amount (in either distance or time) to make sure the short is completely gone before reengaging. The other option is simply to reverse feedrate until the short is no longer detected and then proceed with forward motion.  

I have no idea where to even begin to program this though... :/

Best,
-Dylan

Without a differential probe it's pretty hard so see,
but position recovery really seems like a drive or mechanical stall issue.

Can you set the drive following error limits tighter?

If it's possibly a drive strength issue, you could try single ended wiring.
(Since the drives have optoccoupler inputs this should have little effect on noise immunity)