Search Results (Searched for: )
- endian
yes interpolation servo period.. Rod please check this repo codeberg.org/endian/Beckhoff_AX5ZYZZ_lcec_driver here it is solved at all ... there is a .hal file example and everything neededVery good stuff! I made a start today forum.linuxcnc.org/ethercat/58260-lichua...r-need-help?start=20
is dt = Delta time = servo period?
I'll have to follow you guys a bit more closely!
- rodw
-

is dt = Delta time = servo period?
I'll have to follow you guys a bit more closely!
- grandixximo
-

The lookahead buffer stores velocities and segment data, not pre-calculated positions. Positions are computed at RT execution time through interpolation based on progress values that depend on velocity integration each cycle. The future position you want doesn't exist in a buffer waiting to be exposed.Your HAL component using
0x60B1 (velocity feedforward) can use joint.N.vel-cmd directly - is equal of FF1 of PID which already exist and its widely used to compensaty cycle delay ... this stuff is from my point of view useless for now
but I am still taking just about pin which allready read position from allredy presented 50ms buffer .. you are providing us from sTP posCmd(t), velCmd(t) (command speed is compensated cycle with PID FF1 and we do no use 60B1 for now), accCmd(t) and jerkCmd(t) and we need for ethercat posExtraCmd(t+2) for ethercat devices which is running in Constant Synchronized Position mode because of absention PID and therefore FF1 absention too (2 cycle lag present of ethercat) - this is just array position value which allready exist in buffer because of time(you notice 50ms) precalculation ...
and I know this is topic connected with ethercat but it is directly connected to trajectory planner ... Beckhoff, Codesys, Deltaww it has implemented as I said because their native bus is ethercat ...
- Aciera
- rodw
-

- rodw
-

Not sure if this is final but the states should look like
I need to make sure everything is seperated into readall and writeall functions.
We rtapi_malloc structured data storage when we loadrt so I hope that will work.
The statusword structure looks something like this so the bit fields are mapped overthe status word
When I get a bit further, I'll share via github
- endian
0x60B1 (velocity feedforward) can use joint.N.vel-cmd directly - is equal of FF1 of PID which already exist and its widely used to compensaty cycle delay ... this stuff is from my point of view useless for nowThe pins already exist:
joint.N.vel-cmd - velocity command per joint
joint.N.acc-cmd - acceleration command per joint
joint.N.jerk-cmd - jerk command (useful for S-curve)
These are updated every servo cycle after cubic interpolation, so they represent instantaneous commanded values suitable for feedforward.
For your cia402 component rewrite:
0x60B1 (velocity feedforward) can use joint.N.vel-cmd directly
0x60B2 (torque feedforward) needs joint.N.acc-cmd × inertia, you can do this with a mult2 in HAL or inside your component
No TP changes needed. Just wire the existing pins to your component and map them to the PDOs.
At the moment only joint 0-1-2 jerk-cmd is calculated proper I think, later on we will do all.
but I am still taking just about pin which allready read position from allredy presented 50ms buffer .. you are providing us from sTP posCmd(t), velCmd(t) (command speed is compensated cycle with PID FF1 and we do no use 60B1 for now), accCmd(t) and jerkCmd(t) and we need for ethercat posExtraCmd(t+2) for ethercat devices which is running in Constant Synchronized Position mode because of absention PID and therefore FF1 absention too (2 cycle lag present of ethercat) - this is just array position value which allready exist in buffer because of time(you notice 50ms) precalculation ...
and I know this is topic connected with ethercat but it is directly connected to trajectory planner ... Beckhoff, Codesys, Deltaww it has implemented as I said because their native bus is ethercat ...
- NWE
-

Currently my go-to PLC+HMI setup is LinuxCNC+Node Red dashboard. Sometimes also Glade user interfaces.
I use a combination of Mesa Electronics boards and/or Beckhoff ethercat remote I/O at locations on the machine where you'd normally expect to find a PLC. My logic runs on hal + custom hal components coded in basically C.
Non real-time logic, recipe selections etc. can be configured in node-red pretty much without writing a single line of code unless you want customized functions.
LinuxCNC also has a ladder logic PLC built-in but I cannot inform you of its capabilities, having never used it. I don't care for ladder logic in any form. I have spent way too much time trying to automate complicated machine sequences in expensive proprietary PLC ladder programming software that did not always function the way I expected or wanted.
With node-red for the HMI, all the software lives in the LinuxCNC 'server'. The physical HMIs consist of panel mount touchscreen IPCs booting pretty much any os, autostarting a web browser fullscreen, pointed at the LinuxCNC sever's Node Red web page. The hmi is simply a web page(s) in the server. Placing a duplicate HMI at an additional operator station consists of whatever device you wish, running a web browser displaying the server's web page(s)
I think node-red supports multiple user logins, but I have not tried that feature. In the projects I did so far, I am the only programmer, and the operators don't know how to access the programming back end. Everyone is logged in as me.
On a recent project I set up a router blasting WIFI over the premises. The operator driving the payloader can log into the WIFI with his phone and access the HMI to monitor the processes and switch the machines on/off that he is tending. From the payloader cab.
The entire network is air-gapped from public internet except the server has access to ntp time.
E-stop, safety lockouts, etc are all hardwired with physical safety hardware.
With this system an operator station needs the following wiring:
1. A power cord for the pc.
2. A network cable.
3. A 2 to 6 conductor cable for the E-stop circuit.
When I get more time I'd like to provide some documentation on all this, and some example configs. Currently I'm in the middle of several half finished projects like this, plus a customer running a proprietary PLC I programmed in ladder logic is starting to have random crashes of the PLC, so he is due for an upgrade to LinuxCNC with Glade user interface. This is one more basic machine, so I will skip the node-red. The glade user interface is an app that runs on a monitor plugged directly into the LinuxCNC pc. Then there is a sizable project I'm currently drafting a quote for.
node red getting started:
nodered.org/docs/getting-started/local
I use this for installing node-red:
nodered.org/docs/getting-started/raspberrypi
Although it says raspberry pi, it can be used on an x86/64 pc. During the installation it asks whether I want to install Pi specific nodes, I opt out of that because my x86/64 pc is not a Raspberry pi.
I have been using mqtt messaging to communicate between the LinuxCNC program(s) and node-red. That entails setting up an mqtt server, I have been using mosquitto:
sudo apt install mosquitto
then I run a python-hal component to communicate with node-red via mqtt
Doing all the above configuration pretty much requires a a person to first know his way around linux configuration in the /etc directory extensively.
Default installation of mosquitto and node-red I think listen only on localhost for connection.
Wow, I was going to attach a copy of my python-hal-mqtt connector, but my backup of it seems to be missing. I will have to retrieve a copy from customer's machine as soon as I can.
- grandixximo
-

joint.N.vel-cmd - velocity command per joint
joint.N.acc-cmd - acceleration command per joint
joint.N.jerk-cmd - jerk command (useful for S-curve)
These are updated every servo cycle after cubic interpolation, so they represent instantaneous commanded values suitable for feedforward.
For your cia402 component rewrite:
0x60B1 (velocity feedforward) can use joint.N.vel-cmd directly
0x60B2 (torque feedforward) needs joint.N.acc-cmd × inertia, you can do this with a mult2 in HAL or inside your component
No TP changes needed. Just wire the existing pins to your component and map them to the PDOs.
At the moment only joint 0-1-2 jerk-cmd is calculated proper I think, later on we will do all.
- SOLD
That clarifies the architecture and recovery path perfectly.
I will try external programming on my side based on this.
If I run into anything unclear, I may follow up.
Thanks again for your help.
- Marcos DC
- LinuxCNC handles motion control
- A PLC and HMI handle operator interface, recipes, and simple machine operation (start/stop, part selection, dimensions, safety, etc.)
- How you split responsibilities between PLC and LinuxCNC
- How you manage recipes and part parameters
- How you design a simple HMI for operators
- Any recommended PLC platforms or architectures that integrate well with LinuxCNC
- COFHAL
- rodw
-

- clayton2ndtry
- tommylight
-

Well, 3 days ago this was me in my shop and the temperature was 4 degree C, in a t-shirt for 20 to 30 minutes at a time, nearly 2 hours in total "freezing" time.Actually, I have something around 8°C thats not very comfortable for sitting and fiddeling in my garage.
Recorded a PC build as i had several PC's to build and i rarely record anything, so this time called the services of my brothers photo/video studio, so it should be good.