Advanced Search

Cooped-Up wrote:

was I wrong to change it all to say axis?
./my_LinuxCNC_machine.hal:147: Ini variable '[AXIS_0]P' not found.

Yes, you are wrong, as proven by the error, AXIS_0 P does not exist, but JOINT_0 P should.
-
I deleted my reply, twice, as i can not fathom why...
It is a huge machine with several hundreds of KG of moving mass that can easily break you like a twig, yet you allow yourself to change things you do not understand that will ultimately be controlling that machine!!!
Read, ask, do NOT assume.

If you use a touchscreen, think about what works well with it.

On all the encoders, after power-on, there is a step in the high-res data when the encoder passes the index position. But, there is NO step in the low-res absolute data. My converter board FPGA makes the high-res step disappear as it converts to quadrature. I know WHY Fanuc went with the serial scheme, the quadrature count rates become insane when you start thinking about 1 million counts/rev, and so converting those to quadrature is not practical at full resolution.
Jon

1. Turn off AoE
2. Timing ... 4ms your config != 1ms is your lcec master
3. Refclock cycles has to be something negative as "-1"

Here is working config of the sewlteb from my machine...

 

I would echo what tommylight said,

Axis is not beautiful but when testing hardware I
use it because it can run for months 24/7 with 0 issues

Noted, that was easy enough to change. I noticed my config had said joint in many places over the word axis. was I wrong to change it all to say axis? new debug text

Note: Using POSIX realtime
./my_LinuxCNC_machine.hal:147: Ini variable '[AXIS_0]P' not found.
5235
Stopping realtime threads
Unloading hal components
RTAPI_PCI: Unmapped 65536 bytes at 0x7f09118a1000
Note: Using POSIX realtime

partec wrote:

What exactly do you mean by that TCP?

TCP = Tool Center Piont, the kinematics that keep the tool positioned in the same place no matter how the axis/joints are moving (might not be the best explanation, i know)

partec wrote:

What exactly do you mean by that TRT?

LinuxCNC comes with several 5 axis TCP-TRT simulated configs that also have a Vismach visualization screen/window where the machine can be seen moving, makes things much easier to test.
On the LinuxCNC configuration selecotr, go to sample configurations>sim>axis>vismach>5axis>table-rotary-tilting and choose one of the two configs to run.

partec wrote:

Surely you also have an envelope file (stp or similar)?

Yes, an STL 3D model as shown in the picture above.
Again, thank you very much.

When LinuxCNC added the feature to support multiple spindles, the spindle pin names changed.

for example:

motion.spindle-speed-in

becomes

spindle.0.speed-in
 

That's an odd error since the new mask should be 128=080H
and the existing mask is 255=0FFH
 

I have recently set out (over a year ago) to retrofit my mh800e with linux cnc to make it more user friendly and capable. I had some hurdles with confusion on the mesa cards I am using but I was finally able to make some headway and now have control over the outputs. now I am trying to figure out the mh400e_gearbox program that rotary smp was involved with. if I can figure that out I think I will have a fully functional machine! after I wire everything that is...

here is my debug information
Note: Using POSIX realtime
./my_LinuxCNC_machine.hal:84: Pin 'motion.spindle-speed-in' does not exist
4093
Stopping realtime threads
Unloading hal components
RTAPI_PCI: Unmapped 65536 bytes at 0x7f2494089000
Note: Using POSIX realtime

 

It depends on what you like and are used to.
Personally i like Axis GUI as it is by far the most reliable so for me on industrial machines that wins, but GmoccaPy has a certain flare to it, QtDragon looks like a million $ and Probe Basic is a monster in disguise with all the features implemented into it.

You are welcomed, always.

sudo ./pinirq_2025-10-07.sh enp5s0
returns
"Cores: 8
Old CPU Mask: ff
./pinirq_2025-10-07.sh: line 18: echo: write error: Value too large for defined data type
Set device enp5s0 IRQ 30 CPU mask to ff"

Thanks tommy! After i changed the local language to en_US it worked.

I have the incremental encoders in my lathe, they are the beta versions
however. On these encoders the 10-bit absolute position is there and
accurate enough to use for commutation right from the start. There is
a step in this data however once the encoder passes the index.

The control computer had a backup battery, the battery connection of
the encoders was not used. So I assume the computer was responsible
for remembering the position. There are no homing sensors on the lathe,
so I guess they ran the lathe to its endstops when the battery failed.

For me the hard part was to get the encoder to respond. It wants a
positive pulse on the REQ line, and initially I was trying a negative
pulse. After that, verifying the encoder position was simple enough with
a scope indeed.

The nice part about the CRC is that there are only 32 possible
polynomials, so bruteforcing works like a charm

I hope my information helps someone, but if not... nothing is lost.
I doubt reading the VHDL and C code of hostmot2 would have been faster
than what I did, but I certainly would have tried it, if had known about
it. On the other hand, the microcontroller I use can only capture frames
up to 64 bits, so knowing the padding are actually start and stop bits
was crucial.