Advanced Search

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(output1). 

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

• motion.interp.line-number

   (s32, out)
  The current G-code line number being executed.

• 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

• motion.interp.feedrate

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

Interpreter Geometric Pins

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

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

• motion.interp.arc-center-x

   (float, out)
  The absolute X-coordinate of the center point for the current arc. 0 if in YZ plane

• motion.interp.arc-center-y

   (float, out)
  The absolute Y-coordinate of the center point for the current arc. 0 if in XZ plane

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

• motion.interp.normal-heading

   (float, out)
  the heading from the current point back to the arc centre for the current arc.

• 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

• motion.interp.line-number

   (s32, out)
  The current G-code line number being executed.

• 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

• motion.interp.feedrate

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

Interpreter Geometric Pins

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

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

• motion.interp.arc-center-x

   (float, out)
  The absolute X-coordinate of the center point for the current arc. 0 if in YZ plane

• motion.interp.arc-center-y

   (float, out)
  The absolute Y-coordinate of the center point for the current arc. 0 if in XZ plane

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

• motion.interp.normal-heading

   (float, out)
  the heading from the current point back to the arc centre for the current arc.

• 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

As these are both step-dir I think you could simply set the scales the same in the drives and send them both the same step and direction pulses (at the hardware level)

I feel that I am missing something, though, why are the two parts driven separately if they always rotate as-one?

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
 

The runaway suggests that possibly  one of the feedback loops is reversed.

I vibecoded it with Claude Code. Works a treat!

3404gerber wrote:

I had a quick look at the PortingPlan.md. Am I right to presume that this was AI assisted coding? It's insane how this thing is a game changer for non coder; I have some understanding of coding, read a lot of source code, but am not able to write more than a couple of functions to adapt an existing code (and even that part is mainly copy-pasting form existing libraries). Yet, within three days had a CANopen motor connected to a RPi spinning smoothly in CSP mode. I wouldn't say with Claude-code's help, but rather than Claude-code had it working with some of my contribution for hradware connection and debugging. 

It is AI assisted, Claude in fact!  And yes, Claude did basically all of the actual coding based on existing work.  I did have to do a fair bit of flashing binaries and scoping pins for voltages and timing.  And it does need some guidance for how to fix issues that come up.  It seems very good at writing code given enough direction.  But it doesn't necessarily know which way to do things when there are multiple options available.  It can also go off on tangents when troubleshooting complex problems.  That said, it saves an unbelievable amount of time.  I do have quite a few years of hobby programming experience in a number of contexts, but I've never been a professional programmer.  I'm more into hardware hacking.  So indeed, AI assisted coding is literally game changing for less than great programmers!

C|