Advanced Search

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

RotarySMP has issues with 1 drive causing a fault after a jog, 1 drive faults immediately on jog, and 1 is working OK, so not the same thing as this topic.
This was trying to jog while the drives were disabled, and the subsequent tuning.
RotarySMP has most probably issues with EXE cards that translate whatever feedback Maho uses to pulses.
I though he already figured that out as he did mentioned the same thing on his last video.

forum.linuxcnc.org/49-basic-configuratio...3-axis-router#340542

perhaps also useful for others

 

not with my VFD, if it set to RS485 mode, all other inputs are disabled.

But I'm already trying something.
I'm currently writing a simple Modbus simulator in Python.
I already have an idea of how I can implement it.