I don't think the precision is an actual issue because for both spindle synchronized moves
and spindle orient, index is used so the spindle angle is zeroed before the operation.
This means that you would normally not see a significant loss of precision in the small
number of turns needed by these operations.

Can the EL5151 provide integer counts? If so, they could be easily converted/dewrapped to
a LinuxCNC hal float (which is 64 bits)
 

Was able to successfully run the Motion Studio software to reprogram the ENA input so the drives are disabled by default.

To wire the enables in parallel, a single 5V step/dir pin may not have enough current

Are you suggesting an separate/external 5V power supply for the ENA isolated output? I'm using a HDR-15-5 to power the 7i96s right now. Can I piggyback off that?

Well, I found the reason why this is not an issue: for a long time now, floats have been internally implemented as 64bit double precision, not the 32bit single precision that I assumed.
Not sure how I missed that, sorry.

Yes, resetting the counter/position on the index pulse would mess with the ddt and I am pretty sure also with the spindle synchronized motion.
The EL5151 can provide the period between pulses (or pulse frequency), which can be used to calculate the speed, but getting the correct sign of the speed is a bit annoying.
I just found out about the HAL component generator, which looks like it would make proper signed speed calculation from the raw counter value quite simple, I might try that.

The ddt approach seems to be the one getting recommended most though, so I am still surprised that I couldn't find any mention of issues related to that in combination with the float precision.

I still don't see any way to solve the issues related to the precision of the float position, as that seems to be inherent to the spindle component as it only takes position as float.
As an example:
If a spindle runs at 3000rpm for 8h (which may be somewhat realistic for a long manufacturing day), it gets to 1,440,000 revolutions, which are represented as a float value. At this point, the absolute resolution of the float is reduced to 0.125, or 45° of spindle angle, independent of the (likely much higher) encoder resolution. Isn't that a potential problem?

I am just a hobbyist who will likely never run into that issue, but it would be interesting how this is typically solved for more professional setups with long run times.

I tested it with an IceBreaker board via RS485, but it makes no difference.

for the VFD-Simulation, a USB Modbus adapter is connected to the PC, along with the Python script from above.

Nice! Is that using the rs485 serial output on the RIO board?

The hal file is almost entirely commented out so will not do much.

I would start again (with the original files) and if you get a LinuxCNC startup error, post it here
 

I get around C++ coding some, but this halcomp thing has me confused. I am trying to call several functions within the _ function. As far as I can tell, what I have should work, but when I halcompile it I get these annoying warnings. I know they are just warnings, but I wouldn't mind fixing them.

In other C projects I sometimes use headers, etc, but I'm confused how this works in halcompile.
I searched around some, but can't seem to find examples of how what I'm trying to do would be done in halcomp.

sudo halcompile --install beam_pullmax.comp 
Compiling realtime beam_pullmax.c
beam_pullmax.comp: In function ‘_’:
beam_pullmax.comp:213:5: warning: implicit declaration of function ‘y_stop’ [-Wimplicit-function-declaration]
beam_pullmax.comp:241:6: warning: implicit declaration of function ‘y_down_fast’ [-Wimplicit-function-declaration]
beam_pullmax.comp:286:6: warning: implicit declaration of function ‘y_down_slow’ [-Wimplicit-function-declaration]
beam_pullmax.comp:448:6: warning: implicit declaration of function ‘y_up_slow’ [-Wimplicit-function-declaration]
beam_pullmax.comp:467:6: warning: implicit declaration of function ‘y_up_fast’ [-Wimplicit-function-declaration]
Linking beam_pullmax.so
cp beam_pullmax.so /usr/lib/linuxcnc/modules/

Ah Ha! I think I got it! Just include a header file like any old C program...
I guess I'll post anyway now that it is all typed up, in case it saves someone else time on a future project.

I still have to port it to the main branch, but it already works in dev.

www.youtube.com/shorts/7ieYCgcRN9Q

thank you So I should pin that axis the way you sent it to me, and it will work for me, right? Thank you very much… what do I owe you?

In my case, there is no need to limit the output at zero. I am using pwmgen to generate the 0–10 V signal in type=0, so any negative PID output is clamped to zero.

The PID behaves correctly during ramp-up, since the output is limited to the maximum possible pwmgen value. The derivative gain provides enough damping to prevent overshoot in that direction. However, during ramp-down, there is a small amount of overshoot. It is minimal and perfectly acceptable for my application.

I was just wondering whether it would be useful to have a minoutput pin, allowing the lower limit to be set to zero instead of -maxoutput.

Looking at the manual for this drive I think I can set the control inputs to the terminals and the frequency input to the modbus, I will have to try it later this week.

 

 


 

I just edited the automatically generated .ini and .hal files as needed or commented out lines until LinuxCNC worked. The limit switches, etc. are also not wired yet; I just want to test the old amplifiers once. So, nothing fancy. Maybe I removed too much there or haven't adjusted it yet...?