Advanced Search

Noticed that the code tags in the editor completely mangled the stack traces, here they are in a more readable form.

Error 1:

[qtpyvcp.widgets.input_widgets.gcode_text_edit][INFO]  File encoding: ascii (gcode_text_edit.py:538)
[qtpyvcp.widgets.display_widgets.vtk_backplot.vtk_backplot][INFO] 

---

Draw time 1.4562861919403076 seconds --- (vtk_backplot.py:762)
[qtpyvcp.app.launcher][CRITICAL]  Unhandled exception in vtk_backplot.py line 849 (launcher.py:37)
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/qtpyvcp/widgets/display_widgets/vtk_backplot/vtk_backplot.py", line 849, in load_program
    point_01_pos = self.path_offset_start_point[prev_wcs_index]
                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^
KeyError: 1


Error 2:

[qtpyvcp.widgets.input_widgets.gcode_text_edit][INFO]  File encoding: ascii (gcode_text_edit.py:538)
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 7081, resource id: 8480708, major code: 40 (TranslateCoords), minor code: 0
[qtpyvcp.app.launcher][CRITICAL]  Unhandled exception in vtk_backplot.py line 1174 (launcher.py:37)
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/qtpyvcp/widgets/display_widgets/vtk_backplot/vtk_backplot.py", line 1174, in on_offset_table_changed
    self.rotate_and_translate()
  File "/usr/lib/python3/dist-packages/qtpyvcp/widgets/display_widgets/vtk_backplot/vtk_backplot.py", line 1289, in rotate_and_translate
    self.offset_change_start_actor[wcs_index].SetUserTransform(actor_transform)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
KeyError: 2

It's been a long time since I found any bugs in Probe Basic but this morning I came across a backplot error.

To trigger this bug I loaded the attached g-code file and probed 3 work offsets using the built in probing functionality (G54, G55, G56).

As soon as I probed the final offset G56 I got the first error below.

 

I pressed the ignore button but after that the GUI became partially unresponsive and for example the jog buttons would not work.

Pressing the stop button on the machine gave me the following error.

 

I did some further testing and discovered that if I do the probing first and then open the file I get the same error. However if I do the probing, close Probe Basic and then start it again and open the file I get no error but on the other hand this forces me to rehome the machine which is not optimal from an accuracy perspective.

Seems like the probing routine somehow causes the backplot to crash or leave a bade state somewhere. I tired poking around in the code myself but I'm too inexperienced to put my finger on the exact cause.

If you need any information don't hesitate to contact me here on the forums or via e-mail (This email address is being protected from spambots. You need JavaScript enabled to view it.).
 

Found a way to use the standard plasma component.
After contact (probe-down) I let the contact pulse width be say 5 ms, just long enough for it to register contact.
Always 5 ms and I can compensate for the short distance traveled with the Ohmic Offset setting.
Only downside is the pulse is too short for the Ohmic led to blink.

Checked the ECT60 but I don't see an opening. It has the 0x6077 actual torque pdo but that is always zero.
Homing could be possible. But to switch to homing and lose coordinates and fix that.
I don't think it's currently working badly enough for me to want to put in the time needed.

Bit of an update:

Images have been created for bookworm, the only issue being:
Have to include a /etc/profile.d/linuxcnc-force-realtime.sh script to set up realtime as discussed above.

This one is the breaker for any real testing, booting to first login is to the terminal, has to be manually set for booting to desktop, then rebooted, after that everything is ok. Seeking answers via github so stay tuned.
Goal is for RPi users to feel more at home, except from the desktop change from LXDE to XFCE.
On the creators side, no having to build kernels, kernels come form the rpi repo.

Been there done that too

Ok new power supply hooked up. I am now able to connect to linuxcnc! Onward and upward (at least until the next hurdle)
Thanks so much everyone.

LOL
I wish i could say you are the first one, but many of us did this at some point in time.

I found my mistake. I was editing the wrong file. . . Please excuse me as I leave.

Thank you very much for your professional responses! I’ve decided to order another board along with a daughter card now to avoid a similar failure in the future. I’ll slowly work on repairing the current board, it will serve as a spare one, or I might sell it later. It seems that delivery across Europe will be quite fast using the link you provided. I’ll update you later on how my board recovery story ends.

In your case, you should have gotten a servo/stepper with brake for Z axis.
It is a hardware feature, so software can not help, but if the loop is closed in LinuxCNC at least it will know the position.
PCW's idea with enabling fast after fault and if loop is closed in LinuxCNC is very good.
As for your question, drive fault will disable the motor in the drive, so nothing LinuxCNC can do about it (except above), and so will LinuxCNC disable everything when it gets a fault error.

auto(int[, int]) run, step, pause or resume a program.

This is how I open then run a program in Flex GUI

github.com/jethornton/flexgui/blob/maste...exgui/actions.py#L13

github.com/jethornton/flexgui/blob/maste...xgui/actions.py#L296

assuming you're using a probe you can store the probe results in a file.

JT

I have built my CNC just this month so I have only conducted test cuts, and have not gotten a driver error while machining yet, i just thought such a setup would make more sense if it did happen.

How are errors on drivers on CNC mills usually set up.

I am using Motor Driver CL-HSS860 driver with nema 34 stepper motor.

unknown wrote:

Maybe if I stuck with Mach3 I wouldn't spend so much money, bugger I said the quiet part out load.

But lets face it you might have slashed your wrists by now....

Yes, standard = height set on probing up.
Yes, I saw that hesitation which I think is reducing velocity at probe height which is normal.
Early in the piece, I added a set screw to reduce float switch hysteresis to the barest of minimum.
the second video depends on the float switch to absorb over travel/inertia due to travel speeds.
Yes I don't think a float switch us necessary if you have reliable ohmic probing. In fact my float switch proximity sensor was broken for months and I didn't even know.

I'm not sure about the probing with ethercat, I know some commercial machines sense the material by torque. But if you have torque homing set up and working, perhaps you can use it for material sensing. Maybe you would use the probing function instead. It will be a good experimental project for someone like you

Yes, U22

Here is at least one source:

eu.mouser.com/ProductDetail/Texas-Instru...gQLk2CaRciYmIQ%3D%3D