Advanced Search

Why? Cant you just lock it?

absolutely. I agree that exchanging files through the forum would get cumbersome very quickly once we start iterating.

I’m using GitLab for the development, so I think that would be the easiest solution. I can set up a dedicated repository/project for the testing where you can upload your LinuxCNC configuration, HAL/INI files, custom components, machine documentation, etc. We can then track changes through Git and use issues for individual problems or features.

If you don’t want your machine configuration to be public, that’s no problem, I can make the repository private and give you access directly.

A video call would also be very useful. Especially at the beginning, it would probably save quite a bit of back-and-forth if you could show me the machine architecture, channels, spindles, axes and what you want to achieve.

And yes, the 32 mm Swiss-type machine is exactly the kind of machine I’m looking for. For around $5–6k it could be a very interesting test platform for the multichannel system.

I’ll prepare the GitLab structure and send you access/details.

retrofitcenter wrote:

Yes, it will be open source.

Thank you.

OK, let me know when can i delete this topic.

Todd wrote:

Much of the USA is very rural, and in many places it can be more economical to buy and install a large generator than to get a large 3ph service from a utility.

All the farms around here can get 3ph drops pretty easily - or already have it.  It's really the suburbs and cities/towns that have an issue in this region (NE Ohio).

But I've no idea if those farms have "large" services or just enough amps to run some irrigation pumps and conveyors/fans/elevators.

@retrofitcenter...

This forum has no PM functionality.  Do you have a github repo or similar location where I could provide my config and related files?

I have no issues posting files here, but the inevitable back-and-forth with file transfers during iteration gets really clumsy when done through a forum.

I'd be happy to discuss whatever you'd like during a video call.

This is the sort of thing I'm talking about:  $6k for a 32mm swiss.  Probably get it for 5.

hgrinc.com/productDetail/CNC/Used-Star-M...C-Lathe/11240360356/

Much of the USA is very rural, and in many places it can be more economical to buy and install a large generator than to get a large 3ph service from a utility.

Dear All,

Thank you all for the warm response to our product and for all the feedback so far. The launch offer closed today and is now a regular price of USD 399 for a perpetual license.

Also 1.0.8 has been pushed.

Kind Regards,
George

Thanks for the pointers, and for the prebuilt packages. They make it much easier for others to try this.

For context, here is where I ended up and why.

Hardware and goal
- Beckhoff C6930 industrial PC (i5-7500, 4 cores, no HT), Debian 12, no Beckhoff software.
- LinuxCNC with the IgH EtherCAT master, using an AX5203 drive over SoE.
- Strict 250 µs cycle, plus a custom 5-axis TCP (G43.4/G43.5) and a modified trajectory planner.

What I tried
1. Xenomai 3.3.3 Cobalt on Dovetail (CIP 6.1.170 kernel), built from source with Skylake tuning:
   - Core isolation, no P-states or C-states, tsc=nowatchdog, an i915 workaround and pci=noaer for the PLX backplane switch.
   - The native latency test showed about 3.6 µs max idle and 2.8 µs under load, with 0 overruns.
2. LinuxCNC on that kernel. At the time I was on 2.9 without a Cobalt flavour. Its HAL threads fell back to plain SCHED_FIFO in the Linux root domain, and latency-histogram showed about 36 µs, worse than PREEMPT_RT.
3. Xenomai 4 / EVL, with AI help, using default settings. In my hands it came out worse than PREEMPT_RT.

What I chose
Stock PREEMPT_RT (6.1.0-41-rt-amd64) with core isolation. On the isolated core at 250 µs, cyclictest gave 6–7 µs max, idle and under load. EtherCAT ran for a 30-minute soak with desktop load and stayed stable.

Xenomai's best case saved me about 3 µs, which is irrelevant against a 250 µs budget. To get even that, I would have had to write and maintain a lot of custom code myself: the glue between LinuxCNC, the EtherCAT master and the co-kernel, RTDM-capable NIC drivers, and the tuning for each. I decided that wasn't worth the maintenance, so I stayed on PREEMPT_RT.

What I'd like from this setup
- A hard 250 µs loop with low jitter that I can maintain on a stock Debian kernel.
- No dependence on a patched co-kernel for every kernel update.
- Eventually a self-contained appliance, with safety handled by external TwinSAFE/STO hardware.

Why I'm posting
- It's a great project, and I'm glad it works well for you.
- For anyone with a similar setup, the overhead around the co-kernel is real. On this hardware it buys microseconds, not a different class of determinism.
- If you have a minimal EtherCAT-master-on-EVL setup, or numbers for igb or e1000e with EtherCAT cycles, I'd like to compare. I'll also look at the Xenomai 3 / 4 support in master (issue #3878) with a fresh install.

Regards

Thanks a lot for the detailed description and the offer – that's exactly the kind of machine I'd like to test with.

Your setup is actually a very good candidate, even if it's not a classic swiss. A main spindle with its own X/Z, plus a parting slide and a subspindle that need to synchronise for the hand-off, is precisely the situation where a second channel makes sense. Sequential operations are fine – the interesting part is the synchronisation at the hand-off point, and that's what I want to validate on real hardware. Step/dir with glass scale feedback is also a good test case.

Regarding axis names: the 9-letter limit stays as it is inside each channel. Every channel has its own task, interpreter and trajectory planner, so each channel has its own XYZABCUVW namespace. A G-code program running in channel 2 simply uses X, Z and C – the interpreter doesn't need to know about "C2". The names C1/C2, X1/X2 etc. are the global, channel-qualified identifiers used in the configuration, the HAL side and the GUI, so a swiss with C1/X1/Z1 (main) and C2/X2/Z2 (sub) is no problem. In your case the sub would become a real C axis in channel 2 and take part in that channel's trajectory planner, instead of being an extra joint.

Axes are assigned to a channel in the configuration, and the idea is that an axis can be handed over from one channel to another at runtime (e.g. for a transfer move). That part is still being worked on.

No coding needed from your side – I'll prepare a configuration for your machine and walk you through it step by step. To get started, could you send me:
- your current INI and HAL files
- which hardware/FPGA card you use
- a short sketch or photo of the machine layout (main, sub, parting slide)
- a typical part program, especially the parting/hand-off sequence

Then I'll come back with a proposed 2-channel layout and a test plan. I'll also share screenshots and a short video of the current state soon.

@spumco – thank you very much for the offer, I really appreciate it. I'm based in Austria, not in the US. However, I'll be in California from October 17 to November 17. I'm tied up with an important project during that time, but I'd be glad to meet up while I'm there and talk about how we could move forward – whether that's a machine from HGR or another way to get real swiss-type hardware for testing. I know California isn't exactly next door for you, so a video call would work for me as well. Just send me a PM and we'll find a date.

Thanks again – and thanks @tommylight for the support!

Yes, it will be open source. I’m just still finalizing the first proper release before publishing everything.

At the moment I’m integrating a lot of functionality inspired by industrial CNC systems such as Siemens, especially channel synchronization, spindle/axis synchronization and transformations for turning/milling centers, including face and cylindrical surface machining.

Another major part is the simulation system, including material removal, machine visualization and collision/crash detection.

The tool management is also being heavily extended with a proper tool database, sister tools, lifetime monitoring and 3D models of tools and fixtures.

I’d rather release a solid first version with a clean structure and documentation than publish something half-finished. Once that first release is ready, the source will be made available.

The error messages indicate that transaction 1 & 2 are bad but in reality all are bad.
the first register is a single 16 bit register. I would map functions to decimals. looks like it will become 0=off, 1= on
0 000 stop
1 001 run enable
2 010
3 011
4 100 coast stop
You don't have any hal plumbing.
You need to scale the desired speed to be a frequency in hal so S12000 should resolve to 200 Hz (2000 in register) - assuming normal 400 Hz VFD

Thank you very much for investigating this further and for explaining what you found.

You are absolutely right.

With 400 steps/mm and HOME_OFFSET = 6, the corresponding physical home-switch position in the simulator is:

With the previous switch position at 4000 steps (10 mm), the difference is:

which explains almost exactly the offset you observed between AXIS and the simulator.

So this is not a problem in the switch implementation. The important point is that the positions in virtual-io.conf describe physical switch positions in the simulator's step coordinate system, while HOME_OFFSET tells LinuxCNC which machine coordinate corresponds to the home-switch position.

I agree completely that this is not explained clearly enough at the moment. A user should not have to discover this relationship by trial and error.

I will add a clear explanation and an example directly to virtual-io.conf and also make sure the documentation describes the relationship between the virtual switch position, steps/mm and HOME_OFFSET.

Thank you for taking the time to investigate this instead of simply reporting that something was wrong. Your observation identified a real weakness in the documentation, and your explanation makes the intended behavior much clearer.

This kind of feedback is extremely valuable for the project. Thank you.

Material movement won't work in `machine_test`; it is just a simple configuration for testing purposes. In my configuration, I write the following code in the custom qtdragon handler file:

if (hal.component_exists("vismach")) == False:
    c = hal.component("vismach")
    c.newpin("mat_X_min", hal.HAL_FLOAT, hal.HAL_IN)
    c.newpin("mat_Y_min", hal.HAL_FLOAT, hal.HAL_IN)
    c.newpin("mat_Z_min", hal.HAL_FLOAT, hal.HAL_IN)
    c.newpin("mat_X", hal.HAL_FLOAT, hal.HAL_IN)
    c.newpin("mat_Y", hal.HAL_FLOAT, hal.HAL_IN)
    c.newpin("mat_Z", hal.HAL_FLOAT, hal.HAL_IN)
    c.newpin("mat_X_max", hal.HAL_FLOAT, hal.HAL_IN)
    c.newpin("mat_Y_max", hal.HAL_FLOAT, hal.HAL_IN)
    c.newpin("mat_Z_max", hal.HAL_FLOAT, hal.HAL_IN)
    c.newpin("hide-chuck", hal.HAL_BIT, hal.HAL_IN)
    c.newpin("hide-konik", hal.HAL_BIT, hal.HAL_IN)
    c.newpin("os3", hal.HAL_BIT, hal.HAL_IN)
    c.ready()


STATUS.connect('graphics-gcode-properties',lambda w, d: update_gcode_properties(d))
def update_gcode_properties(props):
    if props != None:
        print ("update update_gcode")

        s = linuxcnc.stat()
        s.poll()

        print("MatPoz        :", s.g5x_offset[2])   

        property_names = {
                'x': "X bounds:",'x_zero_rxy':'X @ Zero Rotation:',
                'y': "Y bounds:",'y_zero_rxy':'Y @ Zero Rotation:',
                'z': "Z bounds:",'z_zero_rxy':'Z @ Zero Rotation:',
                'a': "A bounds:", 'b': "B bounds:",
            }
        #print (props)
        X_poz_min = float((props.get('x_zero_rxy').split())[0])
        Y_poz_min = float((props.get('y_zero_rxy').split())[0])
        Z_poz_min = float((props.get('z_zero_rxy').split())[0])
        X_poz = float((props.get('x_zero_rxy').split())[4])
        Y_poz = float((props.get('y_zero_rxy').split())[4])
        Z_poz = float((props.get('z_zero_rxy').split())[4])
        X_poz_max = float((props.get('x_zero_rxy').split())[2])
        Y_poz_max = float((props.get('y_zero_rxy').split())[2])
#        Z_poz_max = float((props.get('z_zero_rxy').split())[2])
        Z_poz_max = (s.g5x_offset[2])

        # G20 -> G21
        if props.get('gcode_units') == 'in':
            X_poz_min *= 25.4
            X_poz *= 25.4
            X_poz_max *= 25.4

            Y_poz_min *= 25.4
            Y_poz *= 25.4
            Y_poz_max *= 25.4

            Z_poz_min *= 25.4
            Z_poz *= 25.4

        print ("mat_X_min =", X_poz_min,"    mat_X_max =", X_poz_max,"    mat_X =", X_poz)
        print ("mat_Y_min =", Y_poz_min,"    mat_Y_max =", Y_poz_max,"    mat_Y =", Y_poz)
        print ("mat_Z_min =", Z_poz_min,"    mat_Z_max =", Z_poz_max,"    mat_Z =", Z_poz)
        hal.set_p("vismach.mat_X_min", X_poz_min)
        hal.set_p("vismach.mat_X", X_poz)
        hal.set_p("vismach.mat_X_max", X_poz_max)
        hal.set_p("vismach.mat_Y_min", Y_poz_min)
        hal.set_p("vismach.mat_Y", Y_poz)
        hal.set_p("vismach.mat_Y_max", Y_poz_max)
        hal.set_p("vismach.mat_Z_min", Z_poz_min)
        hal.set_p("vismach.mat_Z", Z_poz )
        hal.set_p("vismach.mat_Z_max", Z_poz_max)

So, it writes the dimension positions to the HAL pins, and then, in the handler file, it reads the material dimensions from those pins (just like in that commented-out section that constructs the material).

This function is located in the qtdragon handler file because it isn't called within the vismach file itself when launching vismach in a standalone window; however, this approach allows for launching a second (or subsequent) vismach window without issues (e.g., to test with different parameters).

I'm constantly making tweaks—like saving the machined material to an STL file.
If you have any interesting ideas, let me know.
 

Rod, awesome video! I actually understood a lot more of that sample INI file, definitely had mistakes. hopefully now it is better (but seems like not yet good because it is not working completely).
I have attached:
1) mb2hal.hal file, which at the moment only loads mb2hal module
2) mb2hal.ini file
3) modbus.png which shows few hal pins of the mb2hal module. what I find a good sign there is that first transaction for reading the registers seem good, no errors are accumulated there
4) modbus error.png shows the error message in terminal when I started LinuxCNC there, maybe that is helpful for understanding what am I missing
5) VFD manual
6) VFD modbus register map

I have a suspicion that "First element" in mb2hal.ini is not correct because of the values that are reported on hal pins.Values of those hal pins match following settings from VFD: P-01 (max speed) is set to 24000 and P-02 (min speed) is set to 1800 and P-03 accel ramp time and P-04 decel ramp are both 6.0 seconds

And now as I was writing this, I checked - if I change P-04 parameter (decel time) to 7.0 seconds, mb2hal.status.coast_stop.int immediately changes value to 700 and changing P-03 to 5.6 seconds changes mb2hal.status.reset.int to 560 - hooray I have some basic communication going!
I chose those names according to functions of first 4 bits of register 1 that show status of VFD - I thought that they would reflect values of the first 4 bits, but now I see that they are integer type hal pins, so now I am confused which registers am I looking at.

I took the "First element" value of 128 from very bottom of page 36 of VFD manual (section 8.4 "Modbus register map")

Could you please hint me what am I doing wrong? Because from that register map I understand that register 4 holds accel / decel (from modbus register map it seems that it is one value used for both accel and decel but I proved that those are 2 separate values received from VFD) and I am somehow reading that but I do not see in that map any register that shows min and max speed settings. Where do those come from (got curious and checked - hal pin values are updated immediately when I change those settings in VFD)?

And it seems obvious that if the first transaction is not reading the register that I thought it would then other 2 transactions will not write the register that I thought they would and they produce those errors...

Thanks in advance!