Is there another area that discusses Mesa boards and setting them up

Let me preface this with I am very new to LinuxCNC, Ethercat, and CNCs in general. However, in hopes to help someone else out and maybe keep them interested in getting LinuxCNC working for their CNC I wanted to share my very basic setup files for the Lichaun CL57E-4A 4 axis Ethercat closed looped stepper motor driver. I think these files would be similar to what would be needed for the Lichaun OL57E? I searched the forums for the past few weeks but could not find any working examples for the Lichaun CL57E, (I might just be bad at searching the forum haha). I followed MrRodW's fantastic YouTube tutorial video on how to get all the main Ethercat setup complete and I am using an old HP Elitedesk 800 G1 DM PC, and its built in Ethernet port to run my LinuxCNC setup.

Attached is a very basic Ethercat xml configuration file, that I created with the "lcec_configgen" tool and then I filled in the missing parts by referencing the attached "pdos" and "sdos" files. Also attached are the hal and ini files. With the three files "cl57e-ethercat-conf.xml", "cl57e.hal", "cl57e.ini" a LinuxCNC config can be created and ran, which should in turn allow you to move all four axes. These files are very basic and will need more to get the CNC really going but it is always nice to see the motor move when you tell them too.

Is it possible that there is a grounding issue?

Did the original system use a tachometer?

If so , it would be floating which may be a requirement of the drives input circuit

The runaway only happens when I add a small amount of gain to P.

I've backed up a little to triple check that I have both outputs scaled and the correct directions. The original Fanuc manuals show the test points and expected scales of the input signals for the drives. 

The machine moves 0.2362 inches per revolution and the encoders have 2000 pulses/rev. I used that to calculate an encoder scale which does need to be negative to make the DRO move the correct direction. I then calculated the ratios to get the inches per second of movement that should equate to 10V for both the velocity command and tachometer.

Next I wanted to measure the actual values at the drive. I have the oscilloscope hooked up to the virtual tach signal(output3) and the velocity command signal(output0). I set the PID values back to zero for this test. These images are of the halscope and oscilloscope with a positive value in the tachometer output scale. The pink trace is the tachometer signal(output3) and the yellow trace is the velocity signal(output0). 

These images are with a negative tachometer output. 

With the PID values set to zero, shouldn't analogout0 be zero? it seems to follow analogout3. I've double checked that I dont have a short between the two. 

This is now in master branch 2.10
To see new pins install 2.10 and type man motion
Interpreter Metadata PinsThese pins provide geometric intent and interpreter state for the segment of motion currently being executed. Unlike standard position feedback, these values are synchronized with the trajectory planner’s execution point.Interpreter Status Pins

• Code:

  motion.interp.line-number
   (s32, out)
  The current G-code line number being executed.
• Code:

  motion.interp.motion-type
   (s32, out)
  The type of motion currently in progress:
  • 0: None
  • 1: Rapid (G0)
  • 2: Feed (G1)
  • 3: Arc (G2, G3)
  • 4: Tool Change/Other
• Code:

  motion.interp.feedrate
   (float, out)
  The interpreted feedrate for the current segment in units per minute.

Interpreter Geometric Pins

• Code:

  motion.interp.heading
   (float, out)
  The XY plane heading of the current linear move in degrees. Measured counter-clockwise from the +X axis (0 to 360). This could be used to control a tangential knife.
• Code:

  motion.interp.arc-radius
   (float, out)
  The radius of the current circular move. This value is 0.0 during linear moves. This could be used to modify plasma cutting parameters based on the arc radius and when hole cutting.
• Code:

  motion.interp.arc-center-x
   (float, out)
  The absolute X-coordinate of the center point for the current arc. 0 if in YZ plane
• Code:

  motion.interp.arc-center-y
   (float, out)
  The absolute Y-coordinate of the center point for the current arc. 0 if in XZ plane
• Code:

  motion.interp.arc-center-z
   (float, out)
  The absolute Y-coordinate of the center point for the current arc if in XZ or YZ plane.
• Code:

  motion.interp.normal-heading
   (float, out)
  the heading from the current point back to the arc centre for the current arc.
• Code:

  motion.interp.iscircle
   (bit, out)
  True if the current arc is a full circle and not a helix.

NoteThese pins represent the commanded geometric intent from the interpreter and are updated in real-time as each motion segment is consumed by the trajectory planner. 
 

My original untested theory was that if you knew the arc radius in real time, you could calculate the centripetal radius for a given accelleration and cut speed to know when velocity had to slow down to negotiate an arc. So then on a corner, it might be possible to lock the cut height and move to using current for the process control variable to keep voltage constant. This should keep the kerf width constant.

I also added an motion.interp.iscircle pin so you can sense when the machine is cutting a circle and implement a real time algorithm to improve hole cutting.

And finally, I added tangential heading and normal-heading which is the direction back to the arc centre. The intent here is if you had an appropriate motion head on your plasma torch, you could cut bevels from 2D gcode.

This stuff might be a bit out there, but its there if you guys want to experiment with it with extensions to QTplasmac its there. I've done the hard part for you!

I'll just mention it here as after all its only taken me 6 years to get it into master branch as of this morning. You guys might like to think about how you could use these new pins (taken from man motion) in plasma cutting enhancements.Interpreter Metadata PinsThese pins provide geometric intent and interpreter state for the segment of motion currently being executed. Unlike standard position feedback, these values are synchronized with the trajectory planner’s execution point.Interpreter Status Pins

• Code:

  motion.interp.line-number
   (s32, out)
  The current G-code line number being executed.
• Code:

  motion.interp.motion-type
   (s32, out)
  The type of motion currently in progress:
  • 0: None
  • 1: Rapid (G0)
  • 2: Feed (G1)
  • 3: Arc (G2, G3)
  • 4: Tool Change/Other
• Code:

  motion.interp.feedrate
   (float, out)
  The interpreted feedrate for the current segment in units per minute.

Interpreter Geometric Pins

• Code:

  motion.interp.heading
   (float, out)
  The XY plane heading of the current linear move in degrees. Measured counter-clockwise from the +X axis (0 to 360). This could be used to control a tangential knife.
• Code:

  motion.interp.arc-radius
   (float, out)
  The radius of the current circular move. This value is 0.0 during linear moves. This could be used to modify plasma cutting parameters based on the arc radius and when hole cutting.
• Code:

  motion.interp.arc-center-x
   (float, out)
  The absolute X-coordinate of the center point for the current arc. 0 if in YZ plane
• Code:

  motion.interp.arc-center-y
   (float, out)
  The absolute Y-coordinate of the center point for the current arc. 0 if in XZ plane
• Code:

  motion.interp.arc-center-z
   (float, out)
  The absolute Y-coordinate of the center point for the current arc if in XZ or YZ plane.
• Code:

  motion.interp.normal-heading
   (float, out)
  the heading from the current point back to the arc centre for the current arc.
• Code:

  motion.interp.iscircle
   (bit, out)
  True if the current arc is a full circle and not a helix.

NoteThese pins represent the commanded geometric intent from the interpreter and are updated in real-time as each motion segment is consumed by the trajectory planner.

my eyes glazed over looking at all the options but if its pneumatically actuated, why not a pressure switch? Cheap as chips!

 

Amazing work.

And furthermore 

And there's more

My immediate reaction when I saw your problem was a cascade PID loop. These are two PID loops: fast and slow.
The fast loop is a normal encoder to VFD loop.
The second loop controls the CVT. That controller tries only to keep the output of the first loop at 6V (= 50Hz). I think you do not have to calculate the gear ratio, etc. Maybe it would work without any additional hardware.If the output of the fast controller (VFD) is below 5V, the CVT turns on until it hits the limit or the controller output is above 5V and below 7V. Above 7V, the CVT turns on in the other direction.

If this does not work and feedback from the CVT is needed, a Waterproof Wire Encoder (Aliexpress) can be considered. Then, the PV (actual position of the CVT) can be used to calculate / adjust the $K_p$, $K_i$, and $K_d$ of the fast VFD loop. Mark

That solved the issue.

1. Configured the jumpers on the MESA 7i96S (FPGA card) to Down/Up which set the IP address to 10.10.10.10. This placed it on a separate subnet isolated from my 192.168.1.x main network.
2. Set the IP address of the RPi wired ethernet (ETH0) (Settings/Advanced networking) to the static manual address 10.10.10.1. This placed the RPi ethernet on the same subnet as the MESA.
3. Set the IP address for the WIFI on the RPi to use DHCP. This received an IP address for the main network (192.168.1.110).
4. In Pncconf, set the IP address for the Card (i.e. the MESA FPGA 7i96S) to match the IP address set by the jumper configuration, 10.10.10.10.

Everything now works as expected.

Thanks
Bob

It looks like you  have set the card IP address in the hal file to the host address
rather than the FPGA card address:

hm2_eth: ERROR: Could not retrieve hardware address (MAC) of 10.10.10.1: Connection refused