Advanced Search

Rod, repeat after me:Always use --show, it is disheartening seeing people here get happy looking at results and totally missing the striped columns on both sides of the graph.

where you are not using a parallel port run:
for Mesa, the real test is the network latency.

@Arciera,

Yes. Interesting.

The clothoid takes as input the xy angle and the z angle. Derived from the 3d vector.
I personally should not design the abstract like this, where it uses xy & z angles.
I should prefer to design the abstract in pure 3d vector format. As this is cleaner in my view.
Now we need to transform xy & z angles into 3d vectors etc. I think this could be avoided.

If we should store extra info about a line vector self axis rotation 0 up to 2*M_PI. We could do a clothoid fit with multiple
torsion turns for example. The clothoid fit would then look like a helix fit.

There is still some kind of overfitting in some cases, where the clothoid fit is valid, but takes extra space into the workpiece.
This is inherent to the 4-clothoid-spline fit, as a 2-clothoid-spline can not fit like that, as it has less contrains.

I was considering to create a 2 clothoid spline library based on this 3d clothoid library. This is like downgrading the current
4-clothoid-spline. But will decide that later this year.

Hi Ruediger,

We are aware of spikes. Haha.

Even the most elegant curve seems to show acceleration spikes in halscope.
I dont have the J0 jerk pin here in my axis config.

One way to rule out spikes is to introduce back-end runners. They will filter out all spikes.

Good find btw. And nice you did some research on the codebase.

Both should be perfectly fine even for software stepping to a certain extent.
Although it is strange you got worse base period latency with hyperthreading disabled ... (what is the HTML code for confused?)
Edit:
Forget the last line above, i was looking at the wrong numbers.

Oh hell... (Not addressed at you)
It is the X11/Wayland saga that seems to never end (frankly it moved much faster than i thought, but i would have liked it to move even faster).
Check if X11 or Wayland is in use, and even then the old X11 config style is not used in mint, but there are ways to use it for sure, just needs a bit of searching...and google is cr@p.
I might give it a try searching later, i had found some 3 years ago a nice how to that worked on Mint, but that PC is long gone.

github.com/wezhunter/ESP32_LinuxCNC_MotionController_RealTime

This is not the same project as the other one you posted in, although they are probably related somehow...somewhere...

Thanks a lot Peter and guys.
I wonder why it dropped the CB on one phase of the 3Ph power this time, rather than dropping the 24V DC CB?

The Mesa 7i84 is driving relays on the original MAHO 28A1 card. I don't see any diodes on that board, and I didn't add any.

You can sort of see the diagonal trace the current took through the IC. Which Mesa output number connects to those pins please, so I can concentrate where I am looking for the short?
Cheers;
Mark

roland206 wrote:

All of the pilot arc torch heads I know have an electrode connected to the plasma voltage (negative) and a shield connected to the workpeace.

Oh no!!!!!
Nozzle is not shield.
Nozzle can not be connected to workpiece, although in some "high voltage pilot arc" plasma's it may seems so when measuring, transformers n stuff...
Nozzle is connected to high voltage/high frequency when pilot is on
Shield is an extra layer not connected to anything internally, usually there is a retaining ring and a wire connected to it leading to ohmic sensing parts of the electronics, or not used at all electrically, just for protecting the air stream on multiple gas systems.
Pilot arc is between electrode and shield.
Cutting is between electrode (negative as you already stated) and material/table/clamp that is positive.
During cutting nozzle must be "off or electrically detached" otherwise it would burn to a crisp in 1-2 seconds.

Probably not related to your issue, but may cause issues later on, you may want to implement the zswap changes mention in the RPi sticky. One user had issues when using gmoccapy after being idle. The last couple of posts on that thread discuss the issue and there is a link to the modifications. Sorry about that I really would like to put up new images, but there has been a little push back in that regard.
Cheers
Rob

Yeah just change it to match the name in the ini file, I think the names are pretty agnostic, think variables or similar in C, with a convention in naming that makes it more readable. As long as the value on the right hand side is correct.
If I'm wrong you have my permission to beat me with a stick.
Cheers
Rob

Nevermind, I just tried to run QtDragon and got the following error:
Print file information:
RUN_IN_PLACE=no
LINUXCNC_DIR=
LINUXCNC_BIN_DIR=/usr/bin
LINUXCNC_TCL_DIR=/usr/lib/tcltk/linuxcnc
LINUXCNC_SCRIPT_DIR=
LINUXCNC_RTLIB_DIR=/usr/lib/linuxcnc/modules
LINUXCNC_CONFIG_DIR=
LINUXCNC_LANG_DIR=/usr/lib/tcltk/linuxcnc/msgs
INIVAR=inivar
HALCMD=halcmd
LINUXCNC_EMCSH=/usr/bin/wish8.6
LINUXCNC - 2.9.2
Machine configuration directory is '/home/cnc/linuxcnc/configs/sim.qtdragon.qtdragon_xyz'
Machine configuration file is 'qtdragon_metric.ini'
INIFILE=/home/cnc/linuxcnc/configs/sim.qtdragon.qtdragon_xyz/qtdragon_metric.ini
VERSION=1.1
PARAMETER_FILE=qtdragon.var
TPMOD=
HOMEMOD=
TASK=milltask
HALUI=halui
DISPLAY=qtvcp qtdragon
COORDINATES=XYZ
KINEMATICS=trivkins coordinates=XYZ
Starting LinuxCNC...
Starting LinuxCNC server program: linuxcncsvr
Loading Real Time OS, RTAPI, and HAL_LIB modules
Starting LinuxCNC IO program: io
Starting HAL User Interface program: halui
linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod
Found file(lib): /usr/share/linuxcnc/hallib/core_sim.hal
Found file(lib): /usr/share/linuxcnc/hallib/simulated_home.hal
Starting TASK program: milltask
Starting DISPLAY program: qtvcp
Unexpected realtime delay on task 0 with period 100000
This Message will only display once per session.
Run the Latency Test and resolve before continuing.

Shutting down and cleaning up LinuxCNC...
task: 1466 cycles, min=0.000018, max=0.017806, avg=0.010056, 0 latency excursions (> 10x expected cycle time of 0.010000s)
Removing HAL_LIB, RTAPI, and Real Time OS modules
Removing NML shared memory segments

Debug file information:
Note: Using POSIX realtime
Unexpected realtime delay on task 0 with period 100000
This Message will only display once per session.
Run the Latency Test and resolve before continuing.
link (updating variable file): No such file or directory
QStandardPaths: wrong permissions on runtime directory /run/user/1000, 0770 instead of 0700
[QTvcp.QTVCP.LIB.SYS_NOTIFY][[33mWARNING[0m] Desktop Notify not available:: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Notifications was not provided by any .service files (sys_notify.py:71)
[QTvcp.QTVCP.LIB.QT_NGCGUI.NGCGUI][[33mWARNING[0m] The ngc_sub path does not exist: /home/cnc/nc_files/ngcgui_lib/slot.ngc (ngcgui.py:508)
[QTvcp.QTVCP.LIB.QT_NGCGUI.NGCGUI][[33mWARNING[0m] The ngc_sub path does not exist: /home/cnc/nc_files/ngcgui_lib/qpocket.ngc (ngcgui.py:508)
/usr/bin/linuxcnc: line 977: 9651 Segmentation fault $EMCDISPLAY -ini "$INIFILE" $EMCDISPLAYARGS $EXTRA_ARGS
9611
9647
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime

All I can add is a bit of advice on replacing the chip.
My method of removal is to carefully cut the leads on the chip, not too much pressure just lightly with an exacto knife. Then clean up the pads with desoldering braid.
There's also the flood method, but it requires some very deft action with the soldering iron.
Replacement is pretty easy, lookup the "drag method" on YouTube.
If you have experience with a proper desoldering station and hot air gun, ignore what I've said as you probably realised I'm a ham fisted Aussie.

except you are confused between the torch tip and the shield. Some torches (Hypertherm, and Thermal Dynamcs for example) Have a seperate shield that is not shorted to the workpiece.

So in general if you have an exposed tip you can't do ohmic sensing because its shorted to the material.

Some machines (ie Swiftcut) lower a seperate probe and ohmic probe off that. This can be done fairly easily in QTplasmac with a pneumatic cylinder as all the required signals are there.

I had burned up a few outputs on my 7i84, was able to replace the chip, its the same one as above it in the top row. Worked ever since. As for the blown chip, do the relays have diodes? Is there any potential for a spark from AC to travel back to the mesa from the relay? I personally use mosfet output protectors to protect the expensive mesa cards

Yeah, an instant dead short on the 24V rail could damage the output chips.
It may be repairable by replacing (probably both) NCV7608s
Unfortunately they are obsolete so a bit hard to find, I can probably
mail a couple to you if you want to try.

To make sure the damage is limited to the output chips, so worth repairing,
you could remove the output chips and see if you still have communication
with the 7I84.

Other option would be to replace it with a 7I84U (which is fully compatible
and a bit more rugged)