RPi4 & 7i96 XY2-100 Following Error at High Velocities

That looks OK, Not sure what is going on
I'll try and duplicate this on a RPI4

I looked into this a bit more, and I think its related to the PIDs FF2
being 1 sample late. This causes an apparent ferror spike at the beginning
and and of acceleration. Because its acceleration dependent its not really noticeable
until you have very high accelerations. Also since the error is not velocity dependent
the normal large ferror small min_ferror velocity dependent settings don't help

I suspect you can eliminate the issue by setting the ferror _and min_ferror to say 0.1 mm. Also bounding the PID error may help reduce PID overreaction to this delay

Well, raising Min_Ferror allows it to complete the test Gcode at max velocity. Success!

I have a few questions to help in my understanding

1. There is still ringing in the vel-cmd. I will work on the FF2 number to see it it can improved, but I'm not sure what the ultimate consequence will be. My understanding of the PID function (and what FF2 does) makes me think the best i can do is get the ringing to decay faster but not necessarily do much for the initial overshoot portion. Is this where the max_error comes in? It's almost like it needs some D term in the error function part.

2. I've mapped out the posx_fb and posy_fb and the lines are pretty crisp and straight. There is a bit of a ring in pos values that is directly related to the velocity ringing, but not too bad (probably close enough for my purposes +/- .01mm). Is that pos_fb value essentially the value the card writes to the galvo? ie, it's the direct 16bit output corrected to machine units? I wish there was a pin to see the raw 16bit values being fed to the galvos

You can calculate the 16 bit value because the full range is +-32767 which would be
the full scale range = +-(1/scale)

There are a couple things you can do to reduce the ringing

1. Lower the P term (this is a compromise, lowering it too much will increase the following error)
2. Tune FF2
3. Bound the PID error (set MAX_ERROR to say 0.01 mm)

The position feedback is a scaled floating point representation of the 16 bit galvanometer number
its also has higher resolution (32 bits) so the PID deals with a high resolution number which is
rounded down to 16/18 bits for the galvanometer data.

I found something peculiar in my trials and figured it's worth showing for everyone's reference. Let me know if you think I should start a new thread.

I am currently using a spindle command to M3 and M5 to signify which paths should be laser on and which ones should be non lase movements. In that way, I can use G-code to handle the on/off automatically. The spindle-on pin is wired to a GPIO and fed to the laser. pretty simple on/off switch. I couldn't figure out a better way to do this since there's not really a binary joint-on pin when the joint is being commanded. Joint-active doesn't work since it's always active. So I went with the spindle solution which does work. I just add a M3 or M5 on every line regardless of whether the preceding line has the same spindle command or not. I wrote a script that looks for G1 versus G0. Works pretty well

Example
G1 X10 Y10 M3 (laser on and move to 10,10)
G1 X-10 Y-10 M5 (laser off and move to -10,-10)

Looking at the scope of my spiral program, I noticed there is a slight pause/delay between Gcode commanded positions which should ordinary be a smooth transition.

For example:
G1 X5 Y5 M3 (laser on and move to 5,5)
G1 X10 Y10 M3 (laser on and continue the straight move to 10,10)
G1 X-10 Y-10 M5 (laser off and move to -10,-10)

In the above code, there will be a slight pause (~.021 sec) at the 5,5 point

So I experimented with removing some of the M3 commands from the end of the Gcode commands As you can see in the attached image, the profile of ferror, velx-cmd, posx_fb, and posy_fb changed DRASTICALLY and I'm not sure why



This confuses me as the spindle-at-speed pin is always True so there shouldn't be a delay. I don't really understand why the left half is different than the right half just by removing spindle commands.

Wouldn't you normally use M62 and M63 for this kind of operation?

To be honest, I didn't know those existed until you just pointed them out. Thank you!

I just tried them out and they behave the same as the "no M3/M5" chart shown above. I've got some rework to do with my ini/hal but I think I can make that work and can finally switch over to tuning velocities/accelerations.

I can't thank you enough PCW for all your help.

Dear all, where I can get firmware for 7i96 xy2mod?

freeby.mesanet.com/7i96_xymod.bit

I'll add this to the standard 7I96 distribution when I get a chance