Advanced Search

That is not really helpful, need to know the QtPlasmaC version in the window's header.

For what it's worth, I ran your G-Code on v2.10-009.071, it runs fine.

I added a feature in 2.10 that changes the "VEL:" label to show when a reduction is present. In this case, the line read "VEL@60%: 1020"

It's a program that's intended to pause machine motion (halui.program.pause) anytime the wireless probe controller detects an error (hm2_5i25.0.7i84.0.2.input-24 == 1).

It creates a few HAL pins, one of them being: c.newpin("show-message",hal.HAL_BIT, hal.HAL_OUT) # -> qtdragon.probe-error

I added code to the probe_routines.py file which will set motion.digital-out-02 anytime the probe is in motion (through the MDI command 'M65 P02').

I've been working on the best way to implement error handling while a wireless probe is in motion. I initially tried setting HAL pins directly by patching the probe_routines.py file, but I couldn't get that to work. I then tried tying the same QTDragon dialog to motion.digital-out-00 and then sending a 'G64 P00' in the probe_routines.py before any probe movement. This didn't work as well - I got the same 'HAL: ERROR: signal 'probe-error-msg' already has output pin'. Also, since 'ACTION.CALL_MDI' pauses the UI, I don't think that this method would have worked anyways.

Currently, I have rudimentary error handling implemented by checking a digital input tied to the probe error output before the start of any probe motion (all within probe_routines.py). The subroutine will wait up to 5 seconds for the error to be handled, and will abort if there is no resolution. I tried adding a user interaction dialog box into this routine but I wasn't ever able to display a message to the user while the routine was active. Another issue with this approach is that the subroutine won't halt motion if the probe errors out after a MDI command has been sent, but before the probe has finished its motion.

The idea behind the newest implementation is that anytime the probe is in motion and an error is detected, machine motion will be paused, the user will be prompted for intervention and upon clearing the fault, the routine will resume.

Until fairly recently, I was using probe basic with .ngc files for all the subroutines. I updated and switch to QTDragon, at which point I tried (unsuccessfully) moving over my probe error handling to the python based probe routines.

If there is a different implementation you could think of, I'd love to hear it. I haven't been able to find a solution that's already been implemented. 

Might have helped if you mentioned this to begin with. You really wasted a lot of people's time not giving the whole story.

Out of frustration, I removed the o<word> declarations from the file and loaded the file as a normal g-code program. It worked correctly, start to finish. What ever was happening, mysteriously evaporated.

Thanks for your input and consideration.

Hmmm, nothing obvious wrong.
Maybe vid and pid? Check that Vendor Id and Product Code from "ethercat slaves -v" agrees with vid and pid in ethercat-conf.xml

You can use the loaded tool numbered or named parameters in G Code.
5400 - Tool Number. Volatile.
5401-5409 - Tool Offsets for X, Y, Z, A, B, C, U, V & W. Set by G43. Volatile.
5410 - Tool Diameter. Volatile.
5411 - Tool Front Angle. Volatile.
5412 - Tool Back Angle. Volatile.
5413 - Tool Orientation. Volatile.
#<_tool_offset> - Return 1 if tool offset (G43) is on, else 0.
#<_current_tool> - Return number of the current tool in spindle. Same as #5400.
#<_current_pocket> - Return the tool data index for the current tool.
#<_selected_tool> - Return number of the selected tool post a T code. Default -1.
#<_selected_pocket> - Return the tool data index of the selected pocket post a T code. Default -1 (no pocket selected).

You can use O Codes to do calculations.
linuxcnc.org/docs/stable/html/gcode/o-code.html

This might be a lot easier to do in Flex GUI where you can do calculations in Python.

JT

Flex GUI now has HAL LED's that can be connected up to any out HAL bit or signal and show the on/off status of that bit or signal.

tom-itx.no-ip.biz:443/~webpage/cnc/JT-SHOP/flexgui/LED_Test.mp4

JT

MaHa wrote:

I had time for some investigation. When touchof before running a gcode, (self.gui_path) in the file touchoff.py  leads to /usr/lib/libflexgui. but after running a gcode (self.gui_path) contains /home/miller/linuxcnc/configs.

Toolchange popup is affected also the same way.
 

Thanks for investigating this, this is a big help. I'll get this fixed ASAP.

JT