Advanced Search

Unfortunately Vfdmod is no longer maintained and isn't really a good option for new installs. It was a bit of a pain but I switched to mb2hal. Between the documentation and a few examples I was able to figure it out with some trial and error. I suggest switching to that.

Hello!
Can anybody help me out with this step by step? (I'm not a Linux user)
I have my old setup, but i don't remember how to add Vfdmod to the LCNC, to see the pins and other.
I have now a Buster system with LCNC 2.9.7 and have a "not found file/directory Vfdmod" message.
All old links not works... How to compile it and from where and which file I have no clue...

Progress... so I found this:  forum.linuxcnc.org/38-general-linuxcnc-q...ponent-help?start=10

And that is just what I wish to do; it even works. So now all I need to do is figure out what I did different.
Attached a working example for reference.

Wow, this could get interesting, having to reference hal pins by pointer...

I celebrated too quick 

It compiles without a complaint, but trying to load it with loadrt beam_pullmax throws:
beam_pullmax: dlopen: /usr/lib/linuxcnc/modules/beam_pullmax.so: undefined symbol: y_down_slow

Yes, just use whatever powers the 7I96S +5V

Are you using Trixie? This might be something to take to the debian-user mailing list. I currently have that same problem with every single Debian Trixie install, except all these do not have LinuxCNC. My LinuxCNC is still on Bookworm, that did not have that problem.

I've been meaning to raise the issue on Debian-user but have not yet gotten to it.

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