"On second thought, in this kind of project I might use nested PID" that sounds super fancy, but I see two problems with it for me. For one, I would not know where even to start implementing this. And second, the motor RPM that I get is way too inaccurate for PID to effectively work.

I get the value from a 4–20 mA current from the VFD. I then have a 470 ohm resistor very close to my 7i84 that has the ADC to give me the signal I then process to get an RPM. The signal is rock solid, with no noticeable jitter at all, but it is only an 8-bit ADC, and my voltage is between 1.7 V and a little over 9 V, using less than half of the ADC range.

For getting an approximate gear ratio, this seems fine, but not for actual speed control, at least that is what I think. I may very well be wrong.

The feedback that I used for the spindle is an encoder on the spindle, so I am very confident in this feedback being good. The stuff I am doing with the motor RPM I really do not trust too much. The encoder also has an index, so threading is possible. I don’t want to change that either.

As to “This still leaves you to have to measure the adjustable gearing ratio between spindle and motor for properly scaling the speed command,” the variator is infinitely adjustable. That is why I think even a not completely accurate motor RPM and a really accurate spindle RPM to calculate the gearing ratio every servo cycle would do the trick.

So in a sense, this would only scale the error, as in: if commanded is 1000 and feedback is 800, the error would be -200. Now let’s say we are close to 1:1, then that does not really change, and we actually want the motor to go 200 RPM more.

Let’s say with the same commanded and feedback but a ratio of about 2:1—in that case, we need only about a 100 RPM change on the motor, so scaling the error with the ratio should do that. And as it is just a factor, it will never wildly change the system.

I am sorry if that makes sense only in my head. I have been banging my head against a wall here for some time now.

Regarding my problem 1, I think I have found the reason why the output is between 3000 and -3000. It is this line: [HMOT](CARD0).pwmgen.05.output-type 1
If I read the documentation correctly, it has to be:[HMOT](CARD0).pwmgen.05.output-type 0 to be 0 to 3000. I will see if that helps tomorrow.

On second thought, in this kind of project I might use nested PID:

The inner PID gets its feedback from the motor RPM, its command from the outer PID, its output drives VFD hz command. This PID has to be tuned first, testing it by manually commanding it in motor RPM units.

Next, the outer PID. This gets its feedback from the spindle RPM, its command from LinuxCNC spindle speed command, then its output commands the inner PID.

Am I correct, thinking this will automatically compensate for gearing changes? Except forward/reverse gear change if it exists which would need to be handled by reversing the direction of the outer PID.

Wow! That worked! Thanks so much!

Dudelbert wrote:

I may have not explained what I am after very well. With the variator, if we are properly tuned at 1:1, we would get a problem, as with, for example, 2:1 the same tune would overshoot massively, and with 1:2 we would undershoot.

So what I want is to measure the motor RPM and spindle RPM to get the transmission ratio and scale the PID error accordingly to have a similar response to the point at which it was tuned. I am not after controlling the motor RPM directly.

But to know if this will work or not, I have to get the tune at one point right first, see problem 1 of my previous post.

Just to clarify where your spindle speed PID feedback comes from:
1. Are you using motor RPM for feedback? I think that would be the proper way to do it.
2. Are you using spindle RPM for feedback? To regulate commanded spindle speed? I'm not sure whether there is any easy way to tune that. It seems your tuning would have to change dynamically with the gearing ratio, causing multiple complications.

If I'm correct, ideally the scaling from spindle RPM to motor RPM should be on the PID command signal. At that point the gearing affect on PID tuning should only be mechanical.

This still leaves you to have to measure the adjustable gearing ratio between spindle and motor for properly scaling the speed command.

Its possible but a little awkward do make new firmware with older PKTUART versions
because you need to copy files around to do it.

Can you update to current LinuxCNC  (2.9.

If not I can look into automating the PKTUART versioning as is done for most
modules but that is a fair amount of work.

Note that the full source is available in the 7I96S.zip file

here  is complete setup for 250us position control loop ... with internal homing subroutine and internal probing input mapping for internal precision homing ability... you can select more methods of homing ... pos, pos + latch, neg, neg + latch ... but carefully map everything 

just enjoy !

Hello endian,
thank you very much for your reply.
The AX5201 is working fine now. I didn't read your desciption of your conversion tool carefully. So I exported the "Startup.xml" manually from TC3 and assigned it also manually in ethercat-conf.xml. With the parameters "complete -i" this is done automatically and works fine.
Thanks again!

Hi !
I tested today the new firmware and I have error at loading. Debug file information:Note: Using POSIX realtimehm2/hm2_7i96s.0: Unsupported or inconsistent PktUART TX module (version 3)not loading driver hm2/hm2_7i96s.0: failed to parse Module Descriptor 7hm2_eth: rtapi_app_main: Invalid argument (-22)./The(Mac)Mill(er).hal:9: waitpid failed /usr/bin/rtapi_app hm2_eth./The(Mac)Mill(er).hal:9: /usr/bin/rtapi_app exited without becoming ready./The(Mac)Mill(er).hal:9: insmod for hm2_eth failed, returned -12659Stopping realtime threadsUnloading hal componentsNote: Using POSIX realtime/////////////////////////////////////I noticed that the other 7i96S firmwares use PktUART2. I tried modifying the vhd with the Efinix tools, but it seems I would need the full project sources to properly change the PktUART version and rebuild the firmware. Would it be possible to provide a version of this firmware compiled with PktUART2? It would help a lot.Thanks in advance!

I may have not explained what I am after very well. With the variator, if we are properly tuned at 1:1, we would get a problem, as with, for example, 2:1 the same tune would overshoot massively, and with 1:2 we would undershoot.

So what I want is to measure the motor RPM and spindle RPM to get the transmission ratio and scale the PID error accordingly to have a similar response to the point at which it was tuned. I am not after controlling the motor RPM directly.

But to know if this will work or not, I have to get the tune at one point right first, see problem 1 of my previous post.

Sounds like an asynchronous motor with a couple of percent of slip. I dont think we need to control RPM to any really close tolerance. The only time we do commanded speed change with the tool in engagement is a CSS facing cut, or a taper cut, both of which change speed pretty slowly.

I think it will be a real challenge getting this level of control packaged into the HAL. I started working on a comp for it.

The system accepts 128 digital inputs and 128 digital outputs by simply adding the expansion card on the desired side and updating the loadrt command in the .hal file with the number of expansion inputs/outputs installed. Expansion cards work on either side.

Hi all,

I'm having an issue with LinuxCNC not completing the entire command as written in the G code file.

Here's a piece of the code:
G0 Z1.0000 
(PASS 1)
G1 X-2.3750 Y2.7250 F8
G1 Z-0.0500 F4
G1 X-2.3750 Y1.3915 F8.0000 
G3 X-2.3738 Y1.3811 I0.0211 J-0.0029 F8.0000 
G3 X-2.3585 Y1.3750 I0.0112 J0.0058 F8.0000 
G1 X1.7250 Y1.3750 F8.0000
G1 X-2.3750 Y2.7250 F20
(PASS 2)
G1 X-2.3750 Y2.7250 F8
G1 Z-0.1000 F4
G1 X-2.3750 Y1.3915 F8.0000 
G3 X-2.3738 Y1.3811 I0.0211 J-0.0029 F8.0000 
G3 X-2.3585 Y1.3750 I0.0112 J0.0058 F8.0000 
G1 X1.7250 Y1.3750 F8.0000
G1 X-2.3750 Y2.7250 F20

If I single step the code, the command is completed as written. If I let it run, it completes MOST of the command and then it starts on the next command.

See pic.