Advanced Search

Very 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!
 

There hasn't been any updates to this thread for a while. But the machine has worked great this autumn and I've created some nice billet aluminum car parts.


 

 


However it's finally timed for a much awaited spindle upgrade. I bought this 8000 rpm, liquid cooled BT40 spindle from FUKA/Swift. It seems like a very nice unit but it's gonna be a while before I can test it as I now need to design and manufacture a new head for the milling machine along with a much larger pneumatic tool release cylinder.


 
 

endian wrote:

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 ... 

 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 usingis actually the correct approach given the architecture. It's not a workaround, it's the right way to predict future position from the data that exists.The TP gives you accurate vel-cmd and acc-cmd every cycle. With S-curve planning these will be even smoother and more predictable than with trapezoidal, so your compensation should work better not worse.

Seems to work for me, but maybe you could provide a complete gcode example:

 

Ooops no attachment
 

Well, I made a start and at least have some pins displaying (see attached text file). Still so much to do after a full day on this!

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

grandixximo wrote:

The 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.
 

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 ... 

Some notes on what has been working for me:

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.

The 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.

Thank you very much for the explanation and for providing the complete 7I76 firmware image.
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.

Hello,I work for a company that provides on-site and in-factory service and maintenance for heavy-duty industrial and construction machinery.We are currently developing a large custom machine for laser cleaning and automated painting of heavy equipment and structures. The system will use LinuxCNC as the motion controller, but the machine will be operated by multiple technicians who do not have a G-code programming background.For this reason, we are evaluating the use of a PLC + LinuxCNC architecture, where:

• LinuxCNC handles motion control
• A PLC and HMI handle operator interface, recipes, and simple machine operation (start/stop, part selection, dimensions, safety, etc.)

I would like to hear from others who are using LinuxCNC in an industrial environment with PLC + HMI, especially for machines operated by non-CNC specialists.In particular, I am interested in:

• 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

Any real-world examples or lessons learned would be greatly appreciated.Thank you.

Another error I found is in the io_decoder-keymap.cfg file. In the example, there are comments with #, and when LCN is run, errors appear. I deleted all the extra lines and only left the lines that assign keys to the inputs.

Well 41.8 degrees C here a couple of days ago. A far cry from the -20 degrees C we experienced in Canada at the end of December!

Boy that was easy. I guess I never tried this before without homing every axis.  Thank you!

Muftijaja wrote:

Actually, I have something around 8°C thats not very comfortable for sitting and fiddeling in my garage.

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.
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.