Advanced Search

Spoke too soon.

After verifying the VFD parameters and the loadusr arguments to insure matches, I was able to issue a M3 S6000. The spindle enable relay activated and the spindle ramped up to 6000. However, M5 did nothing and I had to stop the spindle with the VFD control panel.

Next I tried to rerun the M3 S6000 command. I heard the relay activate, but the VFD did not respond. I shut down and restarted LCNC this time it failed to restart complaining that about not being able to communicate with the VFD. Checking dmesg I found that the dongle had migrated from ttyUSB0 to ttyUSB1? I updated the custom.hal and restarted LCNC without issue. This time I issued a M3 S10000 which worked perfectly. but again M5 was ignored.

I've now gone through this sequence several time and each time the VFD starts at the requested speed, then fails to stop. Each time the dongle migrates to a different ttyUSB1/2 port. The last time I issued a start command I noticed that the pyVCP display did not show the speed nor at speed and as I was monitoring the display I saw the OS notify that the dongle had again reattached at a different port.

At this point I'm confident that I can communicate via hy_vfd to VFD, but I'm frustrated that the dongle keeps toggling between ports on its own. Any ideas what is going on and how to resolve the issue?

How about reflashing the mesa 7i77 firmware?

I started linuxcnc in debug mode and when I enable the machine I get this error:

joint 0 following error
emc/task/taskintf.cc 976: Error on joint 0, command number 226
task: main loop took 0.112439 seconds

 

An alternative approach is to create a custom mux2u32.comp component by adapting the existing mux2.comp—replacing its float data types with u32. Once modified, you can compile it with halcompile and integrate it  into your local LinuxCNC.