Move modbus code to separate folder?

[dresco]

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.

[terjeio]

The code can be moved to a separate submodule, but the code has to be changed a bit in order to support more than one client as there are two callbacks that is bound when the Huanyang plugin is initialized. I guess these has to be per transaction instead, to be added to the queue_entry_t struct?

[dresco]

I wonder, could they be chained, and then each client could just ignore if not for it's own modbus slave address? (the rx_exception callback would also need the msg passed back to it for context).

[terjeio]

I wonder, could they be chained

They could, but IMO adding the callbacks to each message is cleaner - and I can get rid of the public modbus_stream_t struct. That would allow access to the modbus code from custom my_plugin.c implementations.

Here is my suggestion (I have not tested the code):

spindle.zip

What do you think?

[dresco]

Thanks, will try and test that tomorrow..

[dresco]

Hi, afraid is not working just yet..

Is faulting - I think because packet is set to NULL by the ModBus_AwaitReply case in modbus_poll(), before the ModBus_Timeout and ModBus_Exception cases are reached in modbus_send(). Checking that packet is non null removes the faults, but then the timeouts and exceptions never actually do anything useful.

I then tried commenting out the packet = NULL in ModBus_AwaitReply instead, as it seems this is done after the callbacks are processed in modbus_send() anyway - but I must be missing something else in the logic, as the regular messages from spindleGetState() just stop..

Cheers, Jon.

[dresco]

Actually, this seems to work (I had been overlooking the different code paths for sync and async packets)..

$ git diff
diff --git a/modbus.c b/modbus.c
index a8c355e..3724a3e 100644
--- a/modbus.c
+++ b/modbus.c
@@ -172,14 +172,15 @@ void modbus_poll (sys_state_t grbl_state)
 
         case ModBus_AwaitReply:
             if(rx_timeout && --rx_timeout == 0) {
-                if(packet->async)
+                if(packet->async) {
                     state = ModBus_Silent;
+                    packet = NULL;
+                }
                 else if(stream.read() == 1 && (stream.read() & 0x80)) {
                     exception_code = stream.read();
                     state = ModBus_Exception;
                 } else
                     state = ModBus_Timeout;
-                packet = NULL;
                 spin_lock = false;
                 if(state != ModBus_AwaitReply)
                     silence_until = ms + silence_timeout;

[terjeio]

Do you think this is an ok way to implement support for multiple clients then?

[dresco]

I only got as far as testing with the Huanyang plugin yesterday. I'll port my proof of concept control panel plugin across today, and try them both together..

[dresco]

Hmm, have them both working independently, but no luck if enabled together.. Thinking perhaps the modbus & serial initialisations should just be called once from driver.c?

#if SPINDLE_HUANYANG > 0
    huanyang_init(modbus_init(serial2Init(115200), NULL));
#endif

#if PANEL_ENABLE
    panel_init(modbus_init(serial2Init(115200), NULL));
#endif

[terjeio]

Thinking perhaps the modbus & serial initialisations should just be called once from driver.c?

Sure - I'll split the modbus_init() to a separate call. Your panel_init() should be without any parameters.

[dresco]

Thanks, can confirm it is working well with two clients now.

Have noticed that the Huanyang VFD appears to intermittently stop responding with a silence of less than ~6ms, leading to timeouts/spindle alarms. My test environment is running at 19200 baud with cheap auto switching RS485 modules, however my modbus slave device (STM32 BlackPill board with FreeMODBUS stack) is reliable at the default 2ms silence, so will blame the Huanyang implementation for now. :)

Also uncovered a small bug while troubleshooting the above - the configured silence timeout was not always respected, due to a 16/32 bit comparison with the ms ticks counter - will confess I scratched my head for some time over this!

diff --git a/modbus.c b/modbus.c
index a8c355e..c965df6 100644
--- a/modbus.c
+++ b/modbus.c
@@ -54,7 +54,7 @@ static const uint32_t baud[]    = { 2400, 4800, 9600, 19200, 38400, 115200 };
 static const uint16_t silence[] = {   16,    8,    4,     2,     2,      2 };
 
 static modbus_stream_t stream;
-static uint16_t rx_timeout = 0, silence_until = 0, silence_timeout;
+static uint32_t rx_timeout = 0, silence_until = 0, silence_timeout;
 static int16_t exception_code = 0;
 static queue_entry_t queue[MODBUS_QUEUE_LENGTH];
 static modbus_settings_t modbus;

Cheers, Jon.

[terjeio]

Thanks, can confirm it is working well with two clients now.

Great, I appreciate the testing you are doing. Perhaps getting closer remove the "experimental" label from the plugin?

... blame the Huanyang implementation for now

Version 1 of the Huanyang protocol is not Modbus compliant in how the messages are made up so I am not surprised. Should the silence delay be made configurable or should we just increase it?

Here is a new version of the code that I believe is closer to how the final version should be:

spindle.zip

I have incorporated your bug fixes in this.

In driver.c initialization will be like this:

#if MODBUS_ENABLE
    modbus_init(serial2Init(115200), NULL);
#endif

#if SPINDLE_HUANYANG > 0
    huanyang_init();
#endif
...

I have added a call for checking if the Modbus plugin managed to install itself:
bool modbus_enabled (void);
this can be called in the initialization function in plugins that wants to be sure that it is available.

Note that the Modbus plugin is not fully configured before settings has been read and acted upon, for that the call
bool modbus_isup (void);
can be used to check the final status.
Both are called from the huanyang code.

Finally the MODBUS_ENABLE symbol has been moved out of modbus.h, you should add it to my_machine.h while testing:
#define MODBUS_ENABLE 1
I will add this in the next commit, but have to update all drivers where the spindle plugin is an option first.

#define MODBUS_ENABLE 2 will also be possible, this will claim the highest numbered auxillary output pin for use as the direction signal.

[dresco]

Great, I appreciate the testing you are doing. Perhaps getting closer remove the "experimental" label from the plugin?
Version 1 of the Huanyang protocol is not Modbus compliant in how the messages are made up so I am not surprised. Should the silence delay be made configurable or should we just increase it?

Thanks, I think I've given it a good testing, but I do have a smaller Huanyang VFD on it's way from China (currently testing with an old 4kW that I had here already). When the new one arrives, I'll compare the silence timeouts and see whether they're consistent. Could then maybe increase the default modbus timeouts to something more suitable if SPINDLE_HUANYANG is defined?

Have noticed that the very first command on startup always ends up in a timeout, will dig into that also...

[dresco]

That initial error was when trying to read the configured speed at 50Hz, was just requesting the wrong register number and getting a NAK. (The default value for rpm_max50 matched the common Chinese spindles, so displayed RPMs were still as expected)..

diff --git a/huanyang.c b/huanyang.c
index 00c1994..7fbb113 100644
--- a/huanyang.c
+++ b/huanyang.c
@@ -331,7 +331,7 @@ static void huanyang_settings_changed (settings_t *settings)
                 .adu[0] = VFD_ADDRESS,
                 .adu[1] = ModBus_ReadCoils,
                 .adu[2] = 0x03,
-                .adu[3] = 122,
+                .adu[3] = 144,
                 .tx_length = 8,
                 .rx_length = 8
             };

That makes me wonder though. This only gets called via huanyang_settings_changed() at startup, so if the spindle isn't responding immediately, then there's no way to get this value without power cycling the board (which is probably tricky once in a cabinet). Perhaps should be called after a reset also?