Advanced Search

tcbmetalworks wrote:

I understand that any computer will do but with my previous set up I've ran into issues with the actual computer being unstable. Halfway threw cutting the thing crashes complete freeze up.

That can be from interference on parallel port, easily.
It can also be failing power supply or memory modules or overheating processor.

tcbmetalworks wrote:

I am looking for a computer that is able to handle being left on for days on end no instability.

With parallel port?
Dell Optiplex 980 big tower
HP Z200
HP Z210
Last two have headers so make sure the port is on the back as it can be removed and is hard to find.
If you want new with parallel port, there is an MSI Tomahawk with B450 or B550 chipset that has a parallel port header, for AMD, but the price for the board only is still higher than the full PC mentioned above.

Tormach's PathPilot CNC controller software is built on top of LinuxCNC.

Yes and Tormach did actually contribute to the Linuxcnc source code some years ago.

Hi Arciera,

Was able to produce the error. This time it could not find clothoid.so
Then i looked into hal-core, how that start's normally.

It uses these lines in the startup script:

# Set the ~/lib path to be found by the system.
sudo ldconfig $(pwd)/../lib
sudo ldconfig $(pwd)/../rtlib

Now these are added here.

This then solved the startup error.
Fingers crossed.






 

Thank you for the reply.
I took a look at the documentation for the home final vel and found this

• HOME_FINAL_VEL = 0.0 - Velocity in machine units per second from home latch position to home position. If left at 0 or not included in the axis rapid velocity is used. Must be a positive number.

My INI specifies 0, defaulting to the axis max velocity of 25mm/s. (this comes into effect at the end of the homing search and never gets that far)

The tandem Y2 axis preforms as expected and the settings in the INI are exactly the same for the problem switch.

Lastly, I suspect the when the Y1 axis starts pushing into the sensor, it's still in the homing routine as an Estop brings an error: "cannot unhome while homing joint 1" This is typically after the tandem joint has already hit its switch and stopped its stepper (presumably waiting for the other side to finish its search)

I've tested some changes in the INI such as

• slowing HOME_LATCH_VEL to .25 (no effect)
• Inverting Y1's final home (no effect)
• Slowing HOME_SEARCH_VEL to 0.5 (no effect)

My understanding of the homing process is that it is supposed search for the switch using the search velocity, hit the switch, back off the switch, and then use the latch velocity to get an accurate measurement. Is there a setting for how far the gantry moves after searching and before the latch process?

I really am at a loss on how to proceed from here.
 

Thanks Chris for your response.

The 3d probe is almost always going to be shorter than the tool length.

Here's what I have added:

225 ; return to original tool-tip position, but using new z-offset
 226 (DEBUG, Return to original tool-tip position using new z-offset: #<local_start_x> , #<local_start_y> , #<local_start_z>)
 227 G53 G0 Z[#<_ini[VERSA_TOOLSETTER]Z_MAX_CLEAR>]
 228 ; now use original (modal)coord system to go over to xy
 229 G0 X[#<local_start_x>] Y[#<local_start_y>]
 230 ; and finally down to the (already offset) z coord
 231 G0 Z[#<local_start_z>]

In the attached/inline image you can see the values of local_start_z of 318.53 which fails. At the end the local_start_z  it is set to 88.717560 and the program then moves forward.

 

I believe that the msg "invalid params in linear command" I believe is actually coming from this line:
 203 G10 L1 P#<tool> Z[#<calculated_offset>]
and there after a G43.

There is mention of another forum post by @sou528 here that mentions the same however there's no follow up to that post .
He does refer to the documentation that indicates an example zworkoffset . If you scan the github repository for the word zworkoffset you will see mention to this.




I'd really like to get this one behind me if at all possible.
 

Unfortunately its not trivial but there are instructions here

forum.linuxcnc.org/27-driver-boards/5366...xcnc?start=20#310794

I really think this should be fixed in the LinucCNC distribution as Realtek hardware is very common
and this affects all Ethernet connected LinuxCNC hardware.

The unfortunate thing is that this (massive Ethernet latency) was broken somewhere between
kernel revisions 4.x and 5.X and has never been fixed (the DKMS fix is a workaround, it should be fixed in
the stock Linux Kernel)
 

Tormach's PathPilot CNC controller software is built on top of LinuxCNC.

OK, as I had almost feared, the DKMS driver issue overwhelms my Debian skills.
Is there a simple tutorial how to do this?

Looks like this might be limited to spindle speed and direction pins not consistently reacting to a program stop as 'spindle.0.on' seems to always clear.


 

No I did not.
Honestly I thought that running update and upgrade would have taken care of that (unless the hardware itself is not compatible). I'm reading about Mesa right now and will probably attempt installing/loading that.
Thank you very much.
Jim

Still does not work.

f you are in the ~/lib dir and do : sudo ldconfig .
The same in the ~/rtlib dir and do : sudo ldconfig .

the commands execute without any output. Trying to a config still fails with the same error. Running ./installer again and opening a config also still fails with the same error.

You can see here how G61/G64 are related to this:

Hm, I'm afraid I don't. You are inserting a tool change which I believe is a queue buster. I'm not sure how the P value in G64 would influence how far ahead the interpreter read ahead is. Could you elaborate a bit?

PCW wrote:

rtt min/avg/max/mdev = 0.044/0.061/9.253/0.062 ms

The 9.253 ms is the issue

I suspect you have Realtek Ethernet hardware so need to install the DKMS driverAh
 
Ah... OK.
So I will try it..
Give you some feedback
 

I Think Your right...
 

Hi Arciera,

Thanks.

I repaired a mistake. The tpmod.so was pointing to the ~/rtlib instead of ~/lib path for finding liblinuxcnchal.so

However my 2 tests worked:
Removed the ~/lib & ~/rtlib content, removed all build dirs. And did ./installer
It just worked.

Then i cloned a new linuxcnc_trajectory_planner into a testdir. Then ./installer.
I worked.

If above isnt working, curious what happens if:
Me thinking your pc is not searching the ~/lib dir.
if you are in the ~/lib dir and do : sudo ldconfig .
The same in the ~/rtlib dir and do : sudo ldconfig .


 

Do you know of an older model that will work? The reason why I ask is I was having screen resolution errors come up when I would use the built in graphics.