Closed Harvie closed 2 years ago
bdring grbl port also has different approach to VFD frequency calculation:
Same as the one grblHAL had originally:
uint16_t value = (uint16_t)(rpm * 100 / 60);
The v2 (H2A) protocol is different, this includes the max rpm setting read from the VFD:
uint16_t data = (uint32_t)(rpm) * 10000UL / rpm_max;
Seems like LinuxCNC does the same for the v1 protocol. I prefer to follow manufacturer specifications, but there are none to be found? I have some documents but they are useless. BTW my latest version for v1 gives the least error, displays correct in grblHAL and wrong in the VFD display. Huanyang should fix their firmware? ;-)
Btw the lroundf()
and rpm+.5
compensation can be used both at the same time...
The commit uses lroundf to fix the RPM issue, and requires lroundf in report.c to get back to original value.
Why does VFD frequency value leave the huanyang subsystem? That seems to be value completely unrelated to anything outside of huanyang plugin, plugin should do all the conversions and its API should only use RPM to communicate with rest of the grblHAL...
Why does VFD frequency value leave the huanyang subsystem?
"Spindle at speed" handling, display of actual RPM in the sender. Don't know what the Huanyang reports back (programmed or actual - hopefully actual), will have to check the manual for clues.
@terjeio interresting summary: https://github.com/bdring/Grbl_Esp32/pull/544#issuecomment-734745004
The manuals are a PITA. I think all that we found are still referenced in our VFD Huanyang code; we ended up using all of them... Fact is that most of them are incomplete and registers don't always report what they should do. It might even be possible that actual frequency is there somewhere in the Huanyang VFD, but we just haven't found it. I don't own a v1 huanyang, otherwise I would consider setting it at some speed, and then attempting to query all the registers to see if one has the right information.
Details:
In any event, if you would happen to find the actual frequency, please let us know!
I wouldn't use floating point to be honest. I've seen VFD spindles with very high RPM values (200K+), so rounding issues will probably occur.
Jumping in late here, as I've just been digging into the Huanyang spindle driver in Grbl_Esp32 while building up my machine.
My interpretation of the Huanyang manual is that the "correct" conversion between RPM and Frequency shouldn't hard-code any constants and should probably be based on PD values from the VFD, though which one(s) is somewhat unclear.
The internet tells me the basic RPM vs Frequency formula is RPM = (120 * Frequency) / # of poles in the motor
- in which case you could read PD143 (Motor Pole Number) to convert between the two -- RPM = 120 * Freq / PD143
. This is where the magic constant 60
comes from in the conversion formula, because most common spindles are 2-pole motors, so /120*2
has been simplified to /60
. (the 100 is just because the Huanyang expects frequency in units of 0.01Hz)
I also see PD144 (Rated Motor Revolution). It's a little hard to parse the translated documentation, but it sounds like the VFD may use this to calculate the RPM that's displayed on the VFD? So an alternative approach seems like RPM = Freq * PD144 / 50
(the 50 is because PD144 is defined as the RPM at 50Hz).
In practice, I suspect most usages of the Huanyang VFD on CNC machines are using the same common 2-pole spindle motors, so the hardcoded constants probably work fine for the vast majority of hobby CNC machines that use Huanyang VFDs...
Separately, I saw the issue of actual RPM (as opposed to the set RPM or frequency) discussed above. This can be found by sending a function 4 (Read status value) message, requesting status field 3 (RoTT). In the version of the manual I was looking at, the example is not correct... I've noted the discrepancy on my work-in-progress Huanyang protocol document and I've confirmed that reading this value works on my Huanyang VFD.
@scottbez1 Thanks for you input. I guess I need to buy a Huanyang VFD to be able to dig into this myself... LinuxCNC reads a bunch of settings on startup that I assume is used later on. Perhaps some useful info can be extracted from that implementation too?
I guess I need to buy a Huanyang VFD to be able to dig into this myself...
What spindle do you currently run on your machine?
What spindle do you currently run on your machine?
Kress FM1050 for the router (has Mach3/ethernet Smootstepper - not going to change to grbl). Small 48V DC motor for the mini router. Washing machine motor with no brandname VFD for the lathe (0-10V control), no RS-485 interface AFAIKT.
I've just checked test branch and i see you've added following settings:
$374: ModBus baud rate:
0 - 2400
1 - 4800
2 - 9600
3 - 19200
4 - 38400
5 - 115200
$375: ModBus RX timeout in milliseconds, range: 50 - 250
can you please add option to set $375=0
in order to ignore unresponsive VFD? I have several use cases:
Is anyone using the Modbus with grblHAL? I've been looking at the Invertek range of VFDs which support Modbus, would it work with other than the Chinese VFDs? Also, how should it be wired to Phil's Teensy 4.1 BOB?
Here's a link to the manual, Modbus description on page 36 - https://inverterdrive.com/file/Invertek-Optidrive-E3-Manual
I don't think this will work without modification with other brands, but the boilerplate code is there and you can probably modify it if you know what modbus commands your unit expects.
Ok, thanks. I'll try to look into it when or if I decide to upgrade the spindle. Or bother you here for help 😅.
More details can be found in this application note.
As @Harvie writes it is unlikely that the Huanyang code can be used as-is, copying it to a new file for Invertek and modifying that to match the Invertek protocol is the way to go ahead. Do not modify the Huanyang code unless it is adding support for further variants or expand functionality for the existing ones.
Thanks @terjeio ,I'll look at the document. But I think it will be above my programming skills to do it. But I am in no rush so there's time to learn something new perhaps. Do you know how it would interface to the @phil-barrett teensy board? Can it be done directly or is some serial to rs485 converter needed?
It needs an RS485 adaptor. That is something I am planning to do. That is one of the reasons the new Pro board has mounting holes for a UART daughter card.
But I am in no rush so there's time to learn something new perhaps.
I think we can sort this out together, for basic control not much code needs to be changed - the largest part of the job is to figure out which commands to send and testing.
Here are 2 cards that might work for you. I have the first (ANMBEST) but think the chip is not really a max485 https://www.amazon.com/ANMBEST-Transceiver-Arduino-Raspberry-Industrial-Control/dp/B088Q8TD4V/ https://www.amazon.com/HiLetgo-Reciprocal-Hardware-Automatic-Converter/dp/B082Y19KV9/
Ok, thanks for the supportive comment . @phil-barrett Do you have an ETA on the new board?
Again I am no hurry to get any of the above, but if it could be sorted sometime this year then it would make a nice Christmas present 😉 .
I'm attempting to get my Huanyang VFD working with grblHAL on a Teensy 4.1
Is this implemented for the Teensy?
I have it defined in _mymachine.h. Is it then just a case of defining the pins in the _T41U5XBBmap.h? Do I comment out the existing spindle definitions, replacing with something like...
I also saw this in the driver.h file for the ESP32, is it necessary?
Am I then good to go after plugging in my 3.3v TTL to RS485 adapter?
I'm attempting to get my Huanyang VFD working with grblHAL on a Teensy 4.1 Is this implemented for the Teensy?
Yes, but is easier than that. You will just need to define VFD_ENABLE=1 and SPINDLE_RPM_CONTROLLED in your my_machine.h (or in platformio.ini if building from that)
Note that you will want to pull the latest code from github.com/grblHAL/, as this repo is the old location and out of date..
Ha! Nothing in my world is ever easy ;P
Thanks for the quick reply Dresco, I'm now with a less archaic version, changed those 2 lines and compiled successfully :)
Should I use the "SPINDLE_ENABLE_PIN" for RX and "SPINDLE_PWM_PIN" for TX?
Presumably there's nothing else I need to change?
It will default to Serial1, which I think is pin 0 for RX and pin 1 for TX. (The RS485 adapters I'm using don't have an enable line, so not sure what pin that would be mapped to if you need it).
Are you using Phils breakout board? If so, just hook your 3.3v TTL to RS485 adapter up to the serial header & should be good to go..
Cheers.
Cool, will give that a go. I'm using a slightly ghetto looking DIY BOB, currently I'm having post upload 'GRBL not found'/'offline' issues with the new GrblHAL when connecting to my all my G-Code senders. :/
Thanks for your help
Ok, so I have the latest GrblHAL up and running and active without spindle, when attempting to enable RS485 control, my sender can see the Teensy but I cannot get communication.
I have the spindle plug in folder with the 3 files and the only code changes I've made are by adding
to _mymachine.h
Apologies for the school boy errors, what am I missing?
Have you gone through the first run settings? It is fairly common for a different configuration to return previous settings to default. Try grounding the halt pin - the default is NC.
Thanks Phil, yes, I inverted all the pins for $5, $6 and $14 on my first setup, the machine started with no alarms and worked as it should - my problem is that when I define VFD_ENABLE 1 and SPINDLE_RPM_CONTROLLED in _mymachine.h, after reboot I get an offline status. Commenting these two lines out gives me my machine back but obviously no VFD control.
Do I need to comment out the default spindle control settings or are they ignored? (I was fearing this would lead to compile issues)
Ok, so I have the latest GrblHAL up and running and active without spindle, when attempting to enable RS485 control, my sender can see the Teensy but I cannot get communication.
Is this the version form the new repository? I am about to archive this to avoid confusion...
after reboot I get an offline status.
Are you connecting to the controller via UART or USB? "Oflline status" is from a sender, does the controller respond if you connect with a terminal application such as puTTY?
Hi Terjeio, yes, after the advice of Dresco, I am now on the correct latest build from the other repository :)
My Teensy 4.1 is connected by USB, senders can identify a port and open a connection, but Grbl communication isn't ready. I've not tried to ssh, what address would I use?
I've not tried to ssh, what address would I use?
Connect via the USB com port. Do you get a response when sending ?
(for getting a real-time report)?
If the the VFD is not set up correctly or the baud rate is wrong the controller will start up with alarm 14 active. Baud rate is set with $374
. Use $help modbus
from the terminal to get info about settings if you can communicate with the controller.
Good news, whilst PuTTY failed to connect (no status or position was returned), the problem was that I was adding SPINDLE_RPM_CONTROLLED to _mymachine.h rather than uncommenting in grbl/config.h
Controller now boots and connects :)
Thanks also for the $modbus tip, I am fiddling with the hardware before connecting it all up.
In my board map, are the Spindle enable, direction and PWM pins redundant? (so I should uncomment them?) Conversely, if I leave the enable pin defined, will it be available to control other relays?
In my board map, are the Spindle enable, direction and PWM pins redundant? (so I should uncomment them?) Conversely, if I leave the enable pin defined, will it be available to control other relays?
Yes. However, if the PWM pin definition is missing it will generate a compiler error unless you update to the version just committed.
the problem was that I was adding SPINDLE_RPM_CONTROLLED to _mymachine.h rather than uncommenting in grbl/config.h
Apologies, that probably came from my suggestion didn't it. I pass the defines in from IDE options, so had overlooked where it's set..
No need to apologise Dresco. All is good. I now have full spindle talkie talkie and no release of magic smoke! 👍
Thanks again for all the help everyone.
Hello, can you please add support for this?
http://fightpc.blogspot.com/2014/10/vfd-control-with-arduino-using-rs485.html