Hello Meister

Since a week, I have been trying to set up a rotary axis A with a TangBob. It works at snail speed, but not at higher speed. I am always confronted with joint follow error of the axis.
I need the axis in a winder setup to wind bobbins. Hence A must rotate "endless" depending on the windings I want to achieve. I need to achieve at least 1000 rpm. There is no problem with a linear axis.
I have used rio-flow-gui to set up an open loop stepper type angular, 1600 micro steps. Scale in and scale out are set to 1600. Whatever I do with the ini parameters to achieve higher speeds it fails on the joint follow error.
As I do not understand the internal mechanics of the actual feedback that should confirm the requested speed, I am lost. Furthermore, I do not understand the fole of the PID, which should have no meaning for an open loop set up.
I also cannot find any example of my application to help me out.
Hence, I hope you can help me out to set up a rotary axis at 1000 rpm to overcome that joint follower error (in simulation mode and with the hardware (currently only with the Tangboard only - no ChinaBob attached).
Thanks a lot in advance.

Unless it's changed in the past few weeks, the existing Lichuan driver doesnt work with the single axis driver.

The lcec_configgen output didn't work due to a few reasons. The auto generated parameter names varied, and there seemed to be something weird going on with sync manager directions causing errors to be generated during initialising 

Can you try a lcec_configgen generated XML file. Your drive should have a native driver now. I did some testing with grandixximo with a Lischuan 4 drive driver....

I think you mean usec not ms. Can you share a screen dump of
latency-histogram --nobase --sbins 1000 --show

Also we need to know the NIC you are using
realtek needs the dkms driver, Intel needs coalescing disabling per man hm2_eth

I suspect its probably OK. IRQ affinity probably needs to be set on startup as it does not persist.

 

So long since I've looked at this but from memory, Dominic's original component was built were he had a drive that homed to index. When I first tried to use it, before the homecomp was devised by Dewey Garrett, we found it needed to set pos_fb = pos_cmd while internal homing  to prevent following errors if using home switches attached to the drive. This was seperate to the homecomp but its still necessary. 
In my homecomp, I have this comment
// RODW - the cia402 comp sets pos_fb = pos_cmd while internal homing to prevent following errors. This could be done here.
github.com/rodw-au/cia402_homecomp/blob/...2_homecomp.comp#L229

So not sure if its covered in Dominic's cia402.comp that you used as a base but I think it should be covered if this becomes an official comp in your ethercat repo.


 

I will make a new release where I have a runtime check for the new symbols I added in ethercat, it's because I have been working on a seperate ethercat branch, with improvements on connectivity time, if you are interested is here

github.com/linuxcnc-ethercat/ethercat

you can also get updates if you install the repo here

github.com/linuxcnc-ethercat/apt

I will work on maintaining compatibility with vanilla ethercat, won't force users to use my ethercat, although IMO it is better

Edit:
Uploaded here, this should work with your ethercat as well
github.com/linuxcnc-ethercat/linuxcnc-et...ases#release-v1.48.0

Hi everyone!

This is my first post here, so a quick introduction. I'm Ruben, a web developer from Melbourne, Australia, who loves building CNC machines. I've been reading this forum for a while as I plan and build my first plasma table. Along the way, I wanted to drive the machine from a touchscreen, a laptop or my phone rather than a screen bolted to the controller. So I built a web interface for QtPlasmaC, and I'd like to share it.

Important: this has not been tested in production yet. My table is still being built, so plasmaweb has only been run against a virtual LinuxCNC machine — the QtPlasmaC simulator config on LinuxCNC 2.9.4, running in a VM — not on a real machine cutting real metal. Please treat it as untested on hardware, try it on a sim config first, and keep a working QtPlasmaC config to go back to (switching back is one INI line, see below). Bug reports and feedback are very welcome.

What it is

plasmaweb replaces the QtPlasmaC screen, not your config. It runs as the LinuxCNC [DISPLAY] program: a Python backend on the controller serves a touch-friendly web UI, and you open it in a browser on the controller itself or on any other machine on your network.It is designed as a drop-in:

• It registers the same qtplasmac HAL component (same 91 pins) that QtPlasmaC does, so your existing postgui HAL files connect unchanged.
• It reads and writes the same files: <machine>.prefs, <machine>_material.cfg and the [QTPLASMAC] INI section.
• Switching over is one line in the INI (DISPLAY = plasmaweb). Setting it back to qtvcp qtplasmac returns the machine to QtPlasmaC.

All reactive and timing-critical logic stays in the realtime plasmac component. The web UI is a dashboard and remote control only: it writes setpoints and one-shot requests, and pins owned by the realtime side are read-only to it. Losing the browser or the network connection never changes machine state.

Features

Plasma screens (mirroring QtPlasmaC's tabs)

• MAIN — live dashboard: arc voltage, THC state, status LEDs, cut recovery, torch pulse, height override, single cut
• PARAMETERS — the QtPlasmaC parameters, saved back to your .prefs file, with QtPlasmaC's own tooltips
• MATERIAL — materials from your _material.cfg, including the M190 material-change handshake
• CONVERSATIONAL — LinuxCNC's own plasmac shape modules, driven from a web form
• PREVIEW — toolpath preview and run-from-line
• STATISTICS — cut counts, arc time and consumable stats

General machine control

• Jogging, homing, MDI, program load/run and the tool table
• Macros, HAL softkeys and external panel inputs
• Uses your machine's own QtPlasmaC colours and keyboard shortcuts from the prefs file
• Layouts for 16:9, 4:3 and portrait (9:16) screens
• English and German UI

Remote access

• Open the UI from a laptop, tablet or phone on your network. Settings shows the address to type in.
• There is no authentication: anyone who can reach the port can jog the machine and fire the torch. Only use it on a network you trust, or set PLASMAWEB_HOST=127.0.0.1 to restrict it to the controller's own screen.

Built-in updates

• When the UI loads, it checks GitHub for a new release and offers Update now / Later / Skip this version. Settings → Updates shows the installed version and has a "Check for updates" button.
• Updates are downloaded over HTTPS and checksum-verified, and are refused while a program is running. Restart LinuxCNC afterwards to use the new version.

LinuxCNC versions: verified against the 2.9.4 simulator. Features that only exist on 2.10 (moving pierce, tube cutting, laser mode, slat height, offset feed rate) are detected from the pins your machine actually exports, and are shown as unavailable rather than as controls that silently do nothing.

Installing

No Node.js needed on the controller. Download the latest release tarball from GitHub and run the installer:

tar xzf plasmaweb-<version>-linux.tar.gz
cd plasmaweb-<version>-linux
sudo ./install.sh

Then in your machine INI:

[DISPLAY]
DISPLAY = plasmaweb

Full guide:   installation.md
Releases:   github.com/RubenAhlhaus/plasmaweb/releases
Source:   github.com/RubenAhlhaus/plasmaweb   (GPL-3.0-or-later)

Credits

This project stands on the work of others, and I want to credit them properly:

• lcncgui (  github.com/salomom/lcncgui  ) — the web application plasmaweb is built on. The backend, the WebSocket layer, and the jog, DRO, MDI, program and tool-table screens all come from lcncgui. plasmaweb adds the plasma layer on top. Huge thanks to its author.
• LinuxCNC and QtPlasmaC / plasmac — the realtime plasmac component does the actual work of running a plasma table, and plasmaweb reuses QtPlasmaC's conversational shape modules, run-from-line logic and G-code handling directly from LinuxCNC rather than reimplementing them. The whole design copies QtPlasmaC's files and HAL interface so that both screens stay interchangeable. Many thanks to Phillip Carter, Gregory Carl and everyone who has contributed to QtPlasmaC and LinuxCNC.

Feedback

If you try it on a sim, or are brave enough to try it on a real table, I'd love to hear how it goes. Please report issues on GitHub or reply here. Since I can't test on hardware yet, reports from people with working tables are especially valuable.Thanks for reading, and thanks to this community for everything I've learned here.

From what I understand - this doesn't have configuration and hal files to match just yet - bit as Mars mentioned it is a complex project - but a cost effective linuxcnc solution would be a big plus to the community. I was considering building an STM32F446 or an STMF32F7xx custom card with a LAN9252 Microchip to use as an EtherCAT controller. This setup might be a lot less expensive overall. Once your team is ready to introduce the wider community to Remora for RP2040 that would be great. I also apprecieate the complexity - and the "small team" working out the details.

I'm starting a new thread for this, as I'm sure other people will likely be looking at these modules. The exact module I have is a AMSAMOTION EC1A-IO16R-AM6, which has 16 Digital Inputs, 16 Digital (relay) Outputs, 4 Analogue Inputs, 2 Analogue Outputs, and a ModBus connection.

The main reason I've selected this module is for the Analogue Inputs, as I want to use one for a Plasma THC, and another for FRO.

I've had it connected for a while, but have been concentrating on the Lichuan drivers first, so as it stands, I've only got as far as the lcec_configgen output -

<slave idx="3" type="generic" vid="0x00000b96" pid="0x00001400" name="D4">
      <!--EC1A-CORE1-->
      <syncManager idx="0" dir="in"/>
      <syncManager idx="1" dir="out"/>
      <syncManager idx="2" dir="out">
        <pdo idx="1601">
          <!--Digital Output process data mapping-->
          <pdoEntry idx="7010" subIdx="01" bitLen="16" halPin="mapping-ch" halType="!!type 002e!!"/>
        </pdo>
        <pdo idx="1603">
          <!--Analog Output process data mapping-->
          <pdoEntry idx="7030" subIdx="01" bitLen="16" halPin="mapping-ch0" halType="u32"/>
          <pdoEntry idx="7030" subIdx="02" bitLen="16" halPin="mapping-ch1" halType="u32"/>
        </pdo>
        <pdo idx="1605">
          <!--Modbus Master Control process data mapping-->
          <pdoEntry idx="7050" subIdx="01" bitLen="32" halPin="tigger-bit" halType="!!type 002f!!"/>
          <pdoEntry idx="7050" subIdx="02" bitLen="32" halPin="clear-bit" halType="!!type 002f!!"/>
          <pdoEntry idx="7050" subIdx="03" bitLen="8" halPin="rs485-enable" halType="!!type 001e!!"/>
        </pdo>
      </syncManager>
      <syncManager idx="3" dir="in">
        <pdo idx="1a00">
          <!--Digital Input process data mapping-->
          <pdoEntry idx="6000" subIdx="01" bitLen="16" halPin="mapping-ch" halType="!!type 002e!!"/>
        </pdo>
        <pdo idx="1a02">
          <!--Analog Input process data mapping-->
          <pdoEntry idx="6020" subIdx="01" bitLen="16" halPin="mapping-ch0" halType="u32"/>
          <pdoEntry idx="6020" subIdx="02" bitLen="16" halPin="mapping-ch1" halType="u32"/>
          <pdoEntry idx="6020" subIdx="03" bitLen="16" halPin="ch2" halType="u32"/>
          <pdoEntry idx="6020" subIdx="04" bitLen="16" halPin="ch3" halType="u32"/>
        </pdo>
        <pdo idx="1a04">
          <!--Data process data mapping-->
          <pdoEntry idx="6040" subIdx="01" bitLen="16" halPin="word0" halType="u32"/>
          <pdoEntry idx="6040" subIdx="02" bitLen="16" halPin="word1" halType="u32"/>
          <pdoEntry idx="6040" subIdx="03" bitLen="16" halPin="word2" halType="u32"/>
          <pdoEntry idx="6040" subIdx="04" bitLen="16" halPin="word3" halType="u32"/>
          <pdoEntry idx="6040" subIdx="05" bitLen="16" halPin="word4" halType="u32"/>
          <pdoEntry idx="6040" subIdx="06" bitLen="16" halPin="word5" halType="u32"/>
          <pdoEntry idx="6040" subIdx="07" bitLen="16" halPin="word6" halType="u32"/>
          <pdoEntry idx="6040" subIdx="08" bitLen="16" halPin="word7" halType="u32"/>
        </pdo>
        <pdo idx="1a05">
          <!--Data process data mapping-->
          <pdoEntry idx="6050" subIdx="01" bitLen="8" halPin="err0" halType="s32"/>
          <pdoEntry idx="6050" subIdx="02" bitLen="8" halPin="err1" halType="s32"/>
          <pdoEntry idx="6050" subIdx="03" bitLen="8" halPin="err2" halType="s32"/>
          <pdoEntry idx="6050" subIdx="04" bitLen="8" halPin="err3" halType="s32"/>
          <pdoEntry idx="6050" subIdx="05" bitLen="8" halPin="err4" halType="s32"/>
          <pdoEntry idx="6050" subIdx="06" bitLen="8" halPin="err5" halType="s32"/>
          <pdoEntry idx="6050" subIdx="07" bitLen="8" halPin="err6" halType="s32"/>
          <pdoEntry idx="6050" subIdx="08" bitLen="8" halPin="err7" halType="s32"/>
          <pdoEntry idx="6050" subIdx="09" bitLen="8" halPin="err8" halType="s32"/>
          <pdoEntry idx="6050" subIdx="0a" bitLen="8" halPin="err9" halType="s32"/>
          <pdoEntry idx="6050" subIdx="0b" bitLen="8" halPin="err10" halType="s32"/>
          <pdoEntry idx="6050" subIdx="0c" bitLen="8" halPin="err11" halType="s32"/>
          <pdoEntry idx="6050" subIdx="0d" bitLen="8" halPin="err12" halType="s32"/>
          <pdoEntry idx="6050" subIdx="0e" bitLen="8" halPin="err13" halType="s32"/>
          <pdoEntry idx="6050" subIdx="0f" bitLen="8" halPin="err14" halType="s32"/>
          <pdoEntry idx="6050" subIdx="10" bitLen="8" halPin="err15" halType="s32"/>
          <pdoEntry idx="6050" subIdx="11" bitLen="8" halPin="err16" halType="s32"/>
          <pdoEntry idx="6050" subIdx="12" bitLen="8" halPin="err17" halType="s32"/>
          <pdoEntry idx="6050" subIdx="13" bitLen="8" halPin="err18" halType="s32"/>
          <pdoEntry idx="6050" subIdx="14" bitLen="8" halPin="err19" halType="s32"/>
          <pdoEntry idx="6050" subIdx="15" bitLen="8" halPin="err20" halType="s32"/>
          <pdoEntry idx="6050" subIdx="16" bitLen="8" halPin="err21" halType="s32"/>
          <pdoEntry idx="6050" subIdx="17" bitLen="8" halPin="err22" halType="s32"/>
          <pdoEntry idx="6050" subIdx="18" bitLen="8" halPin="err23" halType="s32"/>
          <pdoEntry idx="6050" subIdx="19" bitLen="8" halPin="err24" halType="s32"/>
          <pdoEntry idx="6050" subIdx="1a" bitLen="8" halPin="err25" halType="s32"/>
          <pdoEntry idx="6050" subIdx="1b" bitLen="8" halPin="err26" halType="s32"/>
          <pdoEntry idx="6050" subIdx="1c" bitLen="8" halPin="err27" halType="s32"/>
          <pdoEntry idx="6050" subIdx="1d" bitLen="8" halPin="err28" halType="s32"/>
          <pdoEntry idx="6050" subIdx="1e" bitLen="8" halPin="err29" halType="s32"/>
          <pdoEntry idx="6050" subIdx="1f" bitLen="8" halPin="err30" halType="s32"/>
          <pdoEntry idx="6050" subIdx="20" bitLen="8" halPin="err31" halType="s32"/>
        </pdo>
      </syncManager>
    </slave>

Now this obviously doesn't work, as there are a few unknown halTypes, so I'm expecting a few issues along the way to getting this working, however it's a job for tomorrow night, as I'm needing to go and get some sleep, but first step will be getting the Digital IO working.

For a bit more thread completion, this is my current XML for a single CL3-E57H drive -

<slave idx="0" type="generic" vid="00000a79" pid="00001000" configPdos="true">
        <!-- Lichuan CL£-E57H -->
      <dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="0"/>
      <sdoConfig idx="2303" subIdx="00"> <!-- Peak Current -->
        <sdoDataRaw data="a0 0f" />
      </sdoConfig>
      <syncManager idx="0" dir="out">
      </syncManager>
      <syncManager idx="1" dir="in">
      </syncManager>
      <syncManager idx="2" dir="out">
        <pdo idx="1600">
          <pdoEntry idx="6040" subIdx="00" bitLen="16" halPin="cia-controlword" halType="u32"/>
          <pdoEntry idx="6060" subIdx="00" bitLen="8" halPin="opmode" halType="s32"/>
          <pdoEntry idx="607A" subIdx="00" bitLen="32" halPin="target-position" halType="s32"/>
          <pdoEntry idx="60FF" subIdx="00" bitLen="32" halPin="target-velocity" halType="s32"/>
        </pdo>
      </syncManager>
      <syncManager idx="3" dir="in">
        <pdo idx="1a00">
          <pdoEntry idx="6041" subIdx="00" bitLen="16" halPin="cia-statusword" halType="u32"/>
          <pdoEntry idx="6061" subIdx="00" bitLen="8" halPin="opmode-display" halType="s32"/>
          <pdoEntry idx="6064" subIdx="00" bitLen="32" halPin="actual-position" halType="s32"/>
          <pdoEntry idx="606C" subIdx="00" bitLen="32" halPin="actual-velocity" halType="s32"/>
          <pdoEntry idx="6077" subIdx="00" bitLen="16" halPin="actual-torque" halType="u32"/>
          <pdoEntry idx="60fd" subIdx="00" bitLen="32" halPin="digital-inputs" halType="u32"/>
        </pdo>
      </syncManager>
    </slave>

This configures the drive to 4000mA current, and reads the digital inputs to a halPin.
I'll likely expand on it once things are installed on the machine, as I'd like it to fully configure the drive when the machine is powered on, but this is enough to get the basics working for now.

Hello Bob,

We own two old Biesse CNC machines, a Rover 321R (1994) and a Rover 18 (1993), and we are looking to retrofit their obsolete control systems.

We need someone who could help us design, configure and, hopefully, preprogram a complete retrofit control system, preferably retaining the existing DC servo motors and SOPREL drives.

We might also need remote technical assistance, particularly if we cannot find someone locally in Bolivia with the necessary expertise to carry out the installation and commissioning.

Do you think you could help us develop this project?

If so, could you please provide an email address where we can contact you directly? Alternatively, you can reach us at gvargas@lc.com.bo.

Thank you for your time.

Best regards,
Gonzalo Vargas

grandixximo wrote:

a compatible cia402 is released with the latest linuxcnc-ethercat you don't need to compile it yourself, I also rewritten it in C.

github.com/linuxcnc-ethercat/linuxcnc-et...releases/tag/v1.47.0

here is the fixed component in C if you want to take a look

github.com/linuxcnc-ethercat/linuxcnc-et.../master/src/cia402.c
 

I couldn't have known about this, as I didn't examine the source files; I simply used the pre-built package you provided a link to. It doesn't work and instead throws the following error: The `libethercat_1.6.13.g61cc654-1+41.1_amd64.deb` package contains a file named `libethercat.so.1.2.0`, which includes the strings `LIBETHERCAT_1.6` rather than `LIBETHERCAT_1.6.13`—this is likely the cause of the error.

On the other hand, `linuxcnc-ethercat_1.45.0+getset-1+deb12u1_amd64.deb` works, but it does not contain `cia402.so`.
Consequently, I installed version 1.45 and used the `cia402.so` file extracted from the 1.47 package.
The machine works now.

Thank for your works.