Hello Guest it is December 09, 2019, 11:40:35 PM

Author Topic: Is a short blocking delay in PLC script acceptable?  (Read 304 times)

0 Members and 1 Guest are viewing this topic.

Is a short blocking delay in PLC script acceptable?
« on: April 11, 2019, 10:43:49 AM »
I have been developing a serial communications script for continuous data retrieval from a servo drive. I need to delay a very short time between transmitting and receiving to allow the drive to send a response. I initially attempted to use coroutines and a wxTimer (which works fine) but ended up deciding that the complexity of returning data from an asynchronous function was going to be more of a pain that it was worth.

I tested the function just simply using wxMilliSleep() and found it to work perfectly. I am only using a 1ms delay and never miss a transmission.

My question, how bad of a practice is it to have a blocking delay in the PLC script? How much delay is acceptable before the function of Mach 4 is negatively affected?
Re: Is a short blocking delay in PLC script acceptable?
« Reply #1 on: April 11, 2019, 04:34:29 PM »
Hi,
I would have said it was not good practice, but the real question is how bad is it?

My understanding is that the PLC script runs every 10ms or so. It is settable but I can't remember where. Normally
the PLC script runs very quickly so the substantial runtime of the PLC script is going to be the blocking wait state.
That would suggest that the PLC would now consume something like 10% of the available CPU time.

May I suggest opening and pinning the ESS diagnostic to the top and observe the state of the buffer with the blocking
wait state and then again without it. Ultimately if the movement buffer is not adversely affected by the wait state....
who cares?

Craig
My wife left with my best friend...
     and I miss him!
Re: Is a short blocking delay in PLC script acceptable?
« Reply #2 on: April 11, 2019, 07:40:16 PM »
Craig,

Thanks for the thoughts. PLC script rate is under Edit Screen -> profile name at the top of the tree. I have mine set at the default 50ms so roughly 2% of PC time is blocking. I really have nothing important in there so it could easily be set slower if needed.

I was under the impression that the LUA and mach core are completely separated. If I write horrible LUA code like sleep(1 minute), the GUI would freeze for a minute, but the machine motion would continue along perfectly fine. Is this incorrect?

Thanks!
Re: Is a short blocking delay in PLC script acceptable?
« Reply #3 on: April 12, 2019, 12:57:37 AM »
Hi,
my understanding is that the GUI is in one chunk and the Gcode interpreter and motion planner is in the other chunk.
If one chunk blocs the other will see no service. Thus if the GUI blocks then the motion buffer will run out and the machine will
stop.

You could experiment. Try upping the wxMilliSleep to several seconds and see what happens.

Just before you try that it may be that it breaks Mach. If the machine waits for 1 sec every 50ms effectively the machine stops
and therefore you could not edit the PLC script to get rid of the one second wait state. I've had a couple of occasions when
I've broken Mach by putting something in the PLC script which blocks the GUI.

You can get around it by running Mach4.exe from the command line with an /e switch. Mach will open straight into the
screen editor so you can deal with the faulty code.

Craig
My wife left with my best friend...
     and I miss him!
Re: Is a short blocking delay in PLC script acceptable?
« Reply #4 on: April 12, 2019, 08:44:31 AM »
Huh, thats a little concerning  :o

I will mess around with it and report what I find. Thanks again for the thoughts!
Re: Is a short blocking delay in PLC script acceptable?
« Reply #5 on: April 12, 2019, 03:19:31 PM »
Hi,
its not that big a problem if you know that trick.

The first time I did it I was creating some code in the PLC script and used a wxMessageBox() as a diagnostic.
As you know each time a message box comes up you have to dismiss it. Then within milliseconds the PLC script
runs again.....another message box, ie a infinite loop of message boxes which can't be halted to allow you to get
to the screen editor a remove the offending code.

Daz-the-Gaz told me about the command line switch. I had to use it a couple of times.

Craig
My wife left with my best friend...
     and I miss him!
Re: Is a short blocking delay in PLC script acceptable?
« Reply #6 on: April 12, 2019, 04:31:01 PM »
That command line switch is great to know!

You can edit the PLC script in the screen.xml, but going straight to the screen editor seems a lot easier.
Re: Is a short blocking delay in PLC script acceptable?
« Reply #7 on: April 12, 2019, 08:08:18 PM »
Hi,
yes it is a boon if you manage to break Mach4 as I did. The PLC script is a bit of a trap, its easy to end up with infinite
loops and therefore you cannot access the screen editor to repair it.

Before Daz told me about the command line switch I had to reload Mach4 from scratch. I was, and still am, unfamiliar with
profile.xml

I've only had to use the command line switch a couple of times so I just ran through the process to be sure I had it straight.

1) Close Mach4, using WindowsTaskManager if necessary to ensure all elements of Mach4 are closed
2) Open a Command window
3) Change directories to C:\Mach4Hobby (or wherever you have put the root Mach4 directory)
4) type Mach4GUI.exe/e <enter>
5) Select your profile <enter>

Mach4 will now open your profile but in screen edit mode, thus you can remove faulty code.

Craig
My wife left with my best friend...
     and I miss him!
Re: Is a short blocking delay in PLC script acceptable?
« Reply #8 on: April 16, 2019, 01:58:22 PM »
Got the serial code loaded and running! I currently have it reading the drive bus voltage 10 times a second through the PLC script with a 1ms fixed delay. ESS buffer holds steady at ~160 and CPU utilization jumps between 20-30%. So far I haven't seen any issues but I also haven't run the machine using a Gcode file.

First thing to implement will be a bar graph on screen showing spindle load.
Re: Is a short blocking delay in PLC script acceptable?
« Reply #9 on: April 19, 2019, 05:15:46 PM »
Been really busy so not much time in the shop, but I did make the serial code a bit more robust with proper error checking and handling. Now Mach 4/LUA no longer crashes when a serial packet is missed:)

I have tested polling the drives at a rate of 10Hz while jogging with the MPG and while running a simple Gcode program and found no problems. The serial program misses 0 packets while Mach is Idle and maybe 2-3 per minute when it is running code. This does not pose a problem for me at all.

I am going to finalize the serial code this weekend and make many more servo functions (right now the only one I have prints the DC bus voltage). Each function will handle errors differently, so a function which updates the display with information will not care if a single packet is missed, but one which defines the pitch of a thread for rigid tapping would need to retry the transmission or emergency stop the machine before breaking a tap.

The next function I want to create will copy the spindle load to a register to be displayed on a bar graph.

I talked with the guys at Warp9TD some more and they suggested to watch the ESS diagnostics window to make sure the buffer stays sufficiently full while running my code. It does, however I find that running the diagnostic tool really messes up the motion generated by the machine both in MPG mode as well as when running code. As soon as I close the window, machine motion goes back to normal.