Advanced Search

I just checked and I was actually on LinuxCNC 2.9.4. QtPlasmaC version is v2.9-238.315. Is that version effected by the bug you mentioned? I'm going to assume so since the gcode works for you.

I've also just deployed a new version of MetalHeadCAM to metalheadcam.alan-gibson.workers.dev/. I'd really appreciate your feedback on it as I'm specifically targeting QtPlasmaC.

The basic workflow is:
- Click the hamburger menu and then Tools so you can add your tool parameters
- Import a DXF file on the Import stage
- Skip the Edit stage for now as it doesn't do much yet
- Click the topmost Apply button on the Prepare stage
- Add operations to parts and shape chains on the Program stage, making sure to select what you want to cut in the Apply To dropdown.
- Simulate the program on the Simulate stage or just skip it
- Download gcode on the Export stage

Hi All,
I've just released an update that provides improved lead in/out support. Any feedback is of course appreciated.
 

qtdragon.probe-error pin is an I/O pin not an input pin.

I'll have to think more on the best way to add external error checking/handling.
It's a problem spot for linuxcnc.

Ok, sorry for the images. Anyway, I performed all the math on Google Sheets, so you can enter the B-axis position on the ball screw, and it will provide you with the spindle angle, the tooltip x-offset, and the tooltip z-offset. The range of travel for the B-axis is 0 to 305mm. You can enter this in cell Y11, and it will spit out the results. I have also illustrated the drawings better here so that hopefully you can understand. Here is the link . I have looked at the Kinematics tutorial on the website, but I just learn better if I can see someone do a working example. After hours of reading that with Gemini helping with some of the explanations, I don't know how to start writing the code. Anyway, from the tutorial I posted earlier, there is an image of this person's kinematicsInverse function, which I will insert below.

From what I've understood, the job of this function is to understand the required tool tip movement and spit out the number of steps each axis motor needs to make, correct? If that is correct, I should be able to modify the trigonometry here to accommodate my ballscrew articulated B-axis and get this going, hopefully. Because his setup also has an XYZAB setup similar to mine.

If your're running a mes card there is no need to test with a base thread. Servo thread is all that is needed.
Usual advice, turn off power saving, anything that attempts to change clock speed in the BIOS, also turn off hyper threading if that is an option, for a 4 coremachine you might get some relief from isolcpus=2,3

It may help to supply some details regarding the machine you're using.

RADXA Cuby A7Z
radxa.com/products/cubie/a7z/

SoCAllwinner A733 CPU2x Arm® Cortex®-A76 up to 2.0GHz6x Arm® Cortex®‑A55 up to 1.8GHz1x Alibaba RISC-V XuanTie E902 up to 200MHz

GPIO40-Pin GPIO Header with I2C / SPI / PWM / I2S etc

MCU: RISC-V E902 (200MHz) Coprocessor, Real-time tasks and low power management

Unfortunately I didn't see documentation yet

I'm trying to get EasyProbe running on my mill. I had an older version running, but am having problems with the probe signal.
The report file shows: Probe_postgui.hal:14: Pin 'hm2_7i96s.0.gpio.040.in_not' was already linked to signal 'probe-in'
Probe_postgui.hal has:
#

---

Probe signal and LED control (see readme.md)

---

# dbounce_probe.in must be linked to the probe tool input of the interface card
 
setp  dbounce_probe.delay      [PROBE]DEBOUNCE_TIME
setp  xor_probe.in0            [PROBE]PROBE_SWITCH
 
net   probe-raw                dbounce_probe.in             <=    hm2_7i96s.0.gpio.040.in_not
net   probe-switch             dbounce_probe.out            =>    xor_probe.in1
net   probe-signal             xor_probe.out                =>    motion.probe-input pyvcp.probe_led

I can't find any other instances of probe_in. Where might it be?

 

That got me up - but now I've got "Unexpected realtime delay on task 0 with period 1000000"

Latency test gives 60624 ns jitter on the servo thread and 70111 ns jitter on the base thread.

I've been using Linuxcnc for the past 5-6 years (I use to be Clark22 but I got locked out).   More accurately, I've been making baby steps towards getting my cnc to work properly before taking an extended break (build the machine and get it moving, stop for a long break, get the spindle working properly, take a break, get endstops working then take a break ......).  The last big step was getting the spring probe and edge probe to play nicely with each other and then to get the auto tool change and updated tool.table working.  I've don't tend to ask for help but rather keep plugging at it until I get it figured out.  The past month has been going around and around, but today I finally got it working.  I've seen you ask for people to test out the probe_routine.py and the versa_probe.ui and I wanted to let you know that I got it working today and I really like how it's doing.  I have a lot more testing on it to make sure it's actually working but after a month the tool.tbl finally updates.  For anyone else wanting to try these out there's on part that was causing a lot of confusion for me.  the python_probe.py goes in the /usr/lib/python3/dist-packages/qtvcp/widgets/probe_routines.py directory and the versa_probe.ui goes in the /usr/share/qtvcp/widgets_ui directory.  For some reason I had the versa_probe.us in the first directory (who knows how it ended up in there). I thought clarifying that might help somebody.

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