Advanced Search

unknown wrote:

Yeah I could but I'd like to have a Trixe & Bookworm base image to work off. I'll get that going tomorrow (doesn't take too long)

One advantage of the Pi is that you can switch OS as simply as swapping the SD card. 

 

tommylight wrote:

Multi extruders are a real pain to setup and adjust, and this has to be done any time you change the nozzles.

The Prusa XL has load-cells in the extruders. You just take off the build-plate, put the calibration pin in the hole for that purpose and select "calibrate extruders" (or similar) and it taps each extruder in turn against the pin from 4 sides a few times (just like a probing macro with LinuxCNC). 

Admittedly it's not the cheapest of printers, but I don't regret buying it. 

rodw wrote:

Andy, if this is tested as working, can you build an official 2.9.7 release and put it on our repo for bookworm and Trixie?
temp folder does not sound very permanent 

I plan on doing so, but I will have to build all the variants by hand on a selection of VMs and RPis as Buildbot2 seems to be broken. It stalls at the end of the RIP builds: buildbot2.highlab.com/buildbot/#/grid
00-checkin has been running for 1 day and 15 hours at the moment, the previous two builds were killed by me from the IRC interface after similar times stalled. 

 

Led was easily solved with oneshot to qtplasmac.ohmic_led_in.
It works pretty well now. Time to wrap up this project.
The goal was ohmic sensing with the IPTM-60 (and IPTM-80) torch
without modification to the plasma cutter. I think it came out really nice.

A new box was made, needed to measure on what we call the ground lead.
 

The box tucked away
 

Schematics.


All schematics, code etc are available on github
github.com/MetalMusings/MyOwnEtherCATDevice
specifically the Kicad files for the THCLIP board are here
github.com/MetalMusings/MyOwnEtherCATDev...n/Cards/THCLIP/Kicad


 

bnet wrote:

So does this mean that the BLDC module doesn't output commutation before/during the startup indexing procedure? If commutation outputs are suppressed before index pulse is found I may have a problem. I was thinking that it could output them, even if they were off by a little, and hopefully it wouldn't jostle the motor around too much.

I think you are suggesting that you could supply "fake" commutation signals from LinuxCNC to the drive, and that might be enough to persuade the drive to start working?

That might actually work.

If the motor has little enough load on it at startup to magnetically align so that the "fake" commutation becomes true, just long enough for the drive to see the encoder index, then start running off that, you might be able to get things working.

I suppose it's worth a try, it's an hour's work and 3 wires.

So, Parallel Hat ist da, die Mesa Karte noch im Zulauf.

Komme gerade vom ersten Testlauf aus dem Keller - Grundsätzlich positiv, ein paar Dinge laufen aber noch nicht richtig:
- die X-Achse läuft immer nur in eine Richtung, egal welchen Pfeil ich auf der Tastatur drücke (Ich nehme an da passt der DIRX Pin nicht, der war am alten PC invertiert "setp parport.0.pin-03-out-invert 1")
- Alle 3 Achsen laufen zu schnell (gefühlt immer im Schnellgang den man sonst nur mit Shift+Pfeil aktiviert)
- Die Spindelsteuerung fehlt komplett in der Axis GUI

Ich nehme an da muss ich in den .hal und .ini Dateien nochmal nachbessern. Ich habe vieles von der alten Config übernommen, vermutlich gehört da noch was angepasst.

 
 
 

I realized that I forgot to mention which version and branch I'm running.

LinuxCNC: 2.9.4
ProbeBasic: stable branch

Hello,
i already created 4 Gladevcp buttons. X, Y, Z and Home all.

Now i need to know what do to activate them. I guess i need to change may machine.ini or hal.

Thanks

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.