Advanced Search

Thanks for the replies, I should have noted the inhibit logic on the drive itself in my earlier post, but from my interpretation of the datasheet for the 12A8, GND at the input would disable the drive.  Is that correct?
11 INHIBIT IN TTL level (+5 V) inhibit/enable input. Leave open to enable drive. Pull to ground to inhibit drive. Inhibit turns off all power devices.

If so, I would just connect direct to each servo drive with a ground wire connected to the following pins below on the mesa board and then the other side of the floating switch would also go to GND:  
net joint-0-enable joint.0.amp-enable-out => hm2_7i97.0.ssr.00.out-00
net joint-1-enable joint.1.amp-enable-out => hm2_7i97.0.ssr.00.out-01

Alternatively, if I could figure out how to make those into one signal with OR'ed logic for turning ON and AND logic for turning off, I would just drive the 12V relay on the board with one output, however, the Estop approach may be the simplest one to implement when reusing the existing PCB.  

I'm assuming the Mesa board / LCNC don't care if anything is connected to servo enable as long as the motors move when commanded?  Meaning if the servos were enabled externally via Estop for example, the motion control would still work just fine and I could leave out the above two net commands from the HAL file?

No it is not.
FireWire was a very good standard that got killed by corporate greed.
It was also used for networking mainly as interconnect between switches due to it's full duplex speed, besides all DV cameras having it at one point in time.
I liked it and used it plenty, and still have some add on cards rusting away in the shop.

Hi,

I am currently implementing a rack tool changer. My problem is that the Hal Pin "iocontrol.0.tool-prep-pocket" is always Zero. Do I need to activate it in my HAL File? Its currently initialized as following:
My Tool Table looks as follows:
However, even when inserting Tool1 prep-pocket is always 0. Is there something I am missing?
 

Thank you for the reply. Following the video on this thread, I installed the xml provided by the manufacturer but when I try to run linuxcnc I get the error:

~/linuxcnc/configs/sim.axis$ linuxcnc lathe.ini
LINUXCNC - 2.9.3
Machine configuration directory is '/home/phil/linuxcnc/configs/sim.axis'
Machine configuration file is 'lathe.ini'
Starting LinuxCNC...
libnml/buffer/shmem.cc 320: Shared memory buffers toolCmd and toolCmd may conflict. (key=1004(0x3EC))
libnml/buffer/shmem.cc 320: Shared memory buffers toolSts and toolSts may conflict. (key=1005(0x3ED))
libnml/buffer/shmem.cc 320: Shared memory buffers emcError and emcError may conflict. (key=1003(0x3EB))
linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod
Note: Using POSIX realtime
Found file(LIB): /usr/share/linuxcnc/hallib/basic_sim.tcl
setup_kins: cmd=loadrt trivkins coordinates=xz
Found file(REL): ./ethercat.hal
./ethercat.hal:1: lcec_conf exited without becoming ready
Shutting down and cleaning up LinuxCNC...
Note: Using POSIX realtime
LinuxCNC terminated with an error. You can find more information in the log:
/home/phil/linuxcnc_debug.txt
and
/home/phil/linuxcnc_print.txt
as well as in the output of the shell command 'dmesg' and in the terminal


linuxcnc_debug.txt contains:
13223
Stopping realtime threads
Unloading hal components

Linuxcnc_print.txt contains:
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
INIFILE=/home/phil/linuxcnc/configs/sim.axis/lathe.ini
VERSION=1.1
PARAMETER_FILE=sim-lathe.var
TPMOD=
HOMEMOD=
TASK=milltask
HALUI=halui
DISPLAY=axis
COORDINATES=X Z
KINEMATICS=trivkins coordinates=xz
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
Removing HAL_LIB, RTAPI, and Real Time OS modules
Removing NML shared memory segments

Please help, where do I go from here?

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