Advanced Search

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.

Machine must have all axis/joints homed before issuing MDI commands or running in Auto mode.
Or to put it your way, all axis must have the little diamond in front on DRO

What was your user name?

Hello I have been trying to get theses stepper drives configured along with a beckhoff EK1100 and have had no luck at all. I have followed the Ethercat step by step instructions and seem to have hit a wall. Any help would be appreciated. Attached is my pdos and ethercat slaves

 

 

grandixximo wrote:

The CiA 402 standard provides feedforward objects exactly for this: 0x60B1 (velocity offset) and 0x60B2 (torque offset). The master can send position plus velocity feedforward so the drive can anticipate acceleration. This is the standard's solution, it just needs to be mapped in lcec.
Also, good drives interpolate internally. The servo loop runs faster than the bus cycle (Maxon runs 0.4ms internal vs 1ms bus). The drive doesn't jump between positions, it interpolates. That's what 0x60C2 configures.
 

Can we explore this on another topic when I get to it? I wanted to rewrite dominic's cia402 component to make it easier to maintain and properly deal with homing so it comes into line with the custom homing that wasn't around when it was written. So it would be perfect for inclusion. Could the new TP have output pins that could be taken as input to calculate these?   Or how would we do it? Any conversion/massaging would be done in the revised component.

COFHAL wrote:

Thanks, I had an error in the rules file, that's why that error appeared.

Thanks COFHAL! You're right, I found the typo in the README and demo files. I missed a curly bracket in thepart of the udev rule.I've just pushed the fix to the repository. This is exactly why community feedback is so important! Now everything should set up correctly with a simple copy-paste.