grblhal / plugins_spindle Goto Github PK

Apologies, I can only test this with my vfd_support branch modifications and my GS20 VFD , but I just wanted to report my experiences with the new spindle switching feature.

https://github.com/Expatria-Technologies/Plugins_spindle

The switching works as expected, both with the M code and with the startup spindle setting. And when the device is idle or in hold, I can use the spindle speed override and it works as expected. However, if we are in a run state it seems the spindle override is not taking effect. I will try to get some better insights into what could be going on.

Thanks as always for these cool new features.

Hi Terje Io
after the Stepper Spindle do you intend to write a plugin for AC Servo controlled in Modbus to be used as a spindle? I attach you manual (see Chapter 9) and a code for Arduino Nano as an example (also a small video). Greetings

T3a_T3L_manual.pdf
RS485_modbus_AC_servo_eng.ino.txt
https://github.com/grblHAL/Plugins_spindle/assets/7964396/3866e889-1fd2-453d-ad5c-65b04d5a4fba

The risk of current implementation is to miss timeout state in modbus_send_rtu, because second call of modbus_poll will change it to silent.
Currently it works, just because modbus_poll is called from modbus_send_rtu, but this is very dangerous - in other conditions modbus_poll can be called by core main thread, because it hooks grbl.on_execute_realtime.
And I think that intention was that modbus_poll procedure handles this state transition for async packet, whereas for blocking packet timeout state will be changed to silent/idle by modbus_send_rtu code.

Proposed fix:

Additionally, I didn't find on_rx_exception callback for timeout case for async packet.

Shouldn't rx_len be used as loop counter? Otherwise received packed has zero rx_length.

UPD: I see, that rx_len is used below, in CRC check. Ok, then we can't use it in loop. But it is very confusing to get packet in receive callback with zero length. Maybe restore packet->msg.rx_length = rx_len after CRC check?

Hello,

i am trying to get a SIEMENS VFD running but $465 and $466 seem to only accept values up to 255.

In my case the CW and CCW commands would be 1151 and 3199 sice the vfd uses bit 11 for direction.

If i set $465 and $466 to the values 1151 and 3199 it always writes 127 to the modbus register.

Is there any workaround for that?

Thanks in advance!

Hello. Missing comma.

Hi,

Am wondering whether there is an error with the current logic for claiming serial streams?

Have been looking at the F7 driver, and as best as I can see, the instance member checked in the following code is always 0,1, or 2 - and not the number from the SERIALn_PORT / MODBUS_RTU_STREAM definition?

I've been trying to verify this with the F7/H7 Nucleo reference map;

• Without MODBUS_RTU_STREAM defined, it takes the first available stream which works fine.
• With MODBUS_RTU_STREAM defined as SERIAL1_PORT, this also works but I think just coincidentally? As SERIAL1_PORT is defined in the reference map as 1.
• If SERIAL1_PORT is defined as something else (say 11, or 2, or 21), this will result in a [MSG:Warning: Modbus failed to initialize!] error, and then becomes unresponsive.
• Same story if MODBUS_RTU_STREAM / SERIAL2_PORT is used instead. Works fine if defined as 2, but not 1/11/21 etc.

    if(settings.spindle.at_speed_tolerance > 0.0f) {
        spindle_data.rpm_low_limit = rpm / (1.0f + settings.spindle.at_speed_tolerance);
        spindle_data.rpm_high_limit = rpm * (1.0f + settings.spindle.at_speed_tolerance);
    }

This code from huanyang.c applies speed tolerance percentage to the present speed setpoint which implies that speed accuracy of VFDs improve as the speed decreases. For example a 10000 RPM motor with a 1% speed tolerance would be +/- 100 RPM at 10000RPM but +/- 10 RPM at 1000RPM. The physics governing speed accuracy on VFDs cause the the speed accuracy to be the same or worse as the speed decreases. I believe the speed tolerance should always be based on percentage of top speed.
Thanks,
Jeff

The board is MKS Tinybee.

I have several problems with this driver:

• does not increase speed (always works at the min speed set in the register (my set is 7200 rpm));
• M5 does not always stop the spindle, sometimes it stops with M3 S0 or M3 S0 must precede M5;
• M3 and M4 always rotate in the same direction.

I analyzed the data flow on Modbus by comparing a working configuration to verify what happens (I attach the files).
H100 whith FluidNC.txt
H100 whith grblHAL.txt

Whith grblHAL the commands M3, M4 and M5 are received correctly, but he speed S(xxxx) is written in the register with address 512 instead of 513, and I think it is the cause of the speed limitation and maybe also the other problems.

This log is when IOSENDER send M3 S10000 (firmware fluiNC):

[14/09/2023 15:36:49]
Modbus Response (COM11)
Address: 1
Function: 6 (0x06) - Write Single Register
Address: 513
Value: 1666
Checksum: 0x5a73 - OK

[14/09/2023 15:36:50]
Modbus Response (COM11)
Address: 1
Function: 4 (0x04) - Read Input Registers
Byte Count: 4
Values: 05 c2 06 82
Register0: 1474
Register1: 1666
Checksum: 0xd975 - OK

[14/09/2023 15:36:50]
Modbus Response (COM11)
Address: 1
Function: 4 (0x04) - Read Input Registers
Byte Count: 4
Values: 06 6f 06 82
Register0: 1647
Register1: 1666
Checksum: 0x48d0 - OK

[14/09/2023 15:36:50]
Modbus Response (COM11)
Address: 1
Function: 4 (0x04) - Read Input Registers
Byte Count: 4
Values: 06 82 06 82
Register0: 1666
Register1: 1666
Checksum: 0xd8e5 - OK

The spindle run at 10000 rpm correctly.

This log is when IOSENDER send M3 S10000 (firmware grblHAL):

(send M3 S10000)

[14/09/2023 17:21:16]
Modbus Response (COM11)
Address: 1
Function: 5 (0x05) - Write Single Coil
Address: 73
Value: 65280
Checksum: 0x5dec - OK

[14/09/2023 17:21:16]
Modbus Response (COM11)
Address: 1
Function: 6 (0x06) - Write Single Register
Address: 512 <<<<<<<<<<<<<<<<< (not is 513)
Value: 1670
Checksum: 0x0a70 - OK

[14/09/2023 17:21:16]
Modbus Response (COM11)
Address: 1
Function: 4 (0x04) - Read Input Registers
Byte Count: 4
Values: 00 73 00 32
Register0: 115
Register1: 50 <<<<<<<<<<<<<<<<<<< (always locked to 50)
Checksum: 0x8b8a - OK

[14/09/2023 17:21:17]
Modbus Response (COM11)
Address: 1
Function: 4 (0x04) - Read Input Registers
Byte Count: 4
Values: 02 af 00 32
Register0: 687
Register1: 50
Checksum: 0x4bc8 - OK

[14/09/2023 17:21:18]
Modbus Response (COM11)
Address: 1
Function: 4 (0x04) - Read Input Registers
Byte Count: 4
Values: 04 b0 00 32
Register0: 1200 <<<<<<<<<<<<<<<<<<< (instant speeds 1200=7200 rpm)
Register1: 50
Checksum: 0x7a86 - OK

[14/09/2023 17:21:22]
Modbus Response (COM11)
Address: 1
Function: 4 (0x04) - Read Input Registers
Byte Count: 4
Values: 04 b0 00 32
Register0: 1200
Register1: 50
Checksum: 0x7a86 - OK

Register1 (which should set the speed to reach) is blocked at 50. The splindle run to min speed 7200 rpm

I attach the manual of my VFD
new H100 manual V1.8.pdf

Is there anyone who uses this driver or has done any testing?
Thanks

A user of the H7 driver has one of these new Huanyang VFDs.

Has shared a manual here, appears to be Modbus RTU compliant, so I think it should work with @andrewmarles MODVFD spindle type..

I can take some guesses at the settings based on the manual, but wanted to open a ticket here to get some more eyes on it. I would imagine these are going to become more popular.

VFD parameters (page 63).
Looks like it defaults to 19200 baud, even parity, 8 data bits, 1 stop bit.
From memory, grblHAL is expecting N,8,1 - so would need to change parameter P14.02 accordingly.

Modbus registers (page 84)
$462 - Register for Run/stop (default value is 8192) - 8192 (0x2000)
$463 - Set Frequency Register (default value is 8193) - 8193 (0x2001)
$464 - Get Frequency Register (default value is 8451) - 12289 (0x3001)
$465 - Command word for CW (default value is 18) - 1
$466 - Command word for CCW (default value is 34) - 2
$467 - Command word for stop (default value is 1) - 5
$468 - RPM value multiplier for programming RPM (default value is 50) - 100?
$469 - RPM value divider for programming RPM (default value is 60) - 60?
$470 - RPM value multiplier for reading RPM (default value is 60) - ?
$471 - RPM value divider for reading RPM (default value is 100) - ?

Page 85 mentions settings P00.01, and P00.02 needed for Modbus control, although P00.02 is not listed anywhere else in manual?

Reproduction:

1. Build on RP2040 with modbus vfd enabled
2. $$
3. RP2040 hangs

Cause seems to be wrong datatype (Integer instead of Int16)

This is fixed in #19.

the name of my VFD is Delta VFD015EL21A. Will it work?

Hi Terje, how would you feel about moving the modbus files out of here to their own folder? I think this would be cleaner for any future plugins that also use modbus..

Don't think I can make a pull request for this, as it would need a new submodule - but changes would be (1) creating a new 'modbus' source folder in STM32CubeIDE, (2) moving the two modbus.* files, and (3) changing the include path in huangyang.h as follows;

diff --git a/spindle/huanyang.h b/spindle/huanyang.h
index 22d8e41..e8f219c 100644
--- a/spindle/huanyang.h
+++ b/spindle/huanyang.h
@@ -37,7 +37,7 @@
 #endif
 #define VFD_SPINDLE 1
 
-#include "modbus.h"
+#include "modbus/modbus.h"
 
 void huanyang_init (modbus_stream_t *stream);

I have a Huangyang VFD here on the bench that I'm testing with, using the STM32F4xx driver. (My interest here is that I'm picking up on my modbus control panel & plugin work again).

Regards, Jon.

Looks like the refactoring has impacted speed control for original Huanyang VFDs..

Here it's setting spindle_hal->rpm_max to the configured RPM @ 50Hz, which is then enforced in spindle_set_rpm()

I have just started testing the stepper spindle. The obvious practical issue I feel is spindle enable and axis enable both are hard bound somewhere in code, so I cant really move an axis to a precise location while rotating the spindle by hand to see if the tool touched the surface. All the other parameters like Spindle enable, direction, rpm, acceleration, works as expected.

The dynamic spindle selection seems to work well for VFD spindles when they are selected as spindle > 0. The is_vfd_spindle and _is_modvfd_selected functions expose the appropriate settings and they appear to work as expected.

But if I set the default spindle to be one of the VFD spindles, it never enumerates correctly. $476 is never exposed, nor do the MODVFD settings if that spindle is selected. It does appear that the MODVFD spindle is in fact being activated by the core as I can see traffic on the RS485 interface and it generates error14 when it can't communicate. I have spent a fair amount of time trying to figure out where it is going wrong but no success yet.

We just had an in depth discussion with some users on the VFD pluging reporting unexpected behaviour such as: gcode commencing before spindle at speed (despite a tolerance and delay being set) and also the spindle seemingly ignoring settings and not alarming out despite not having reached speeds at the defined time.

Reported settings:

$340: Spindle at speed tolerance: 5 percent
$392: Spindle on delay: 1 sec

The users VFD was configured for a 10 sec ramp.
Expected behaviour would be that the controller issues an alarm 14 after 1 sec because spindle is at around 2400rpm during the 1 sec aceleration time.

Observed behaviour:
M3 S18000 - alarm 14 after 1 sec
M3 S10000 - acelerates for 10 sec to 10000rpm, no alarm was issued after 1 sec
M3 S12000 - also acelerates slowly, no alarm after 1 sec
M3 S13000 - also acelerates slowly, no alarm after 1 sec
M3 S14000 - alarm 14 after 1 sec -

after digging through the code a bit i found this: (in huanyang.c - line 130 )

 if(settings.spindle.at_speed_tolerance > 0.0f) {
            spindle_data.rpm_low_limit = rpm / (1.0f + settings.spindle.at_speed_tolerance);
            spindle_data.rpm_high_limit = rpm * (1.0f + settings.spindle.at_speed_tolerance);
        }

Since the spindle at speed tolerance is also stored as a two digit decimal i believe the tolerance limits are calculated wrongly.
For example the tolerance of 5.0 from above would result in the folowing checks:
18000rpm / 6 = 3000rpm lower limit - which correctly errors out
10000rpm / 6 = 1666rpm lower limit - this passes the 1 second check interval and continues to acelerate to full issued speed
this explains why S14000 ist starting to fail as it should, it's crossing the 2400rpm aceleration line of the vfd

i believe the relevant portion of the code should look like this to function correctly as a percentage:

        if(settings.spindle.at_speed_tolerance > 0.0f) {
            spindle_data.rpm_low_limit = rpm / (1.0f + (settings.spindle.at_speed_tolerance / 100));
            spindle_data.rpm_high_limit = rpm * (1.0f + (settings.spindle.at_speed_tolerance / 100));
        }

Hope i got everyting right and this helps.

Am going to have another look at spindle load reporting for VFD spindles, this time just as a percentage (following discussion in previous PR, and in line with how it's done on other machines).

Am planning to query the maximum amps during spindle configuration, and then the actual amps periodically along with the rpm. Can then use a calculated load percentage for feedback in the realtime report etc. So far so good..

I have a question though, I only want to add this additional report data if the spindle is selected. For instance if I switch away from the Huanyang spindle to the PWM spindle with M104, then I'd want to stop adding the data in the Huanyang plugin realtime report. Is there a way within the spindle plugin to determine whether the spindle is currently active?