Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Andrew S on July 08, 2019, 04:57:16 PM
-
I've spent the past week banging my head against my monitor, trying to figure out why my PUBLISH messages wouldn't always get sent. Here's the code structure:
1. Stage with SUBSCRIBE for 4 subscriptions.
2. Each time the subscription receives a message I SGSET to a stage specific to the subscription and PUBLISH an appropriate message back to the broker, then I SGRST the stage.
What I have been finding is that the first PUBLISH takes a long time to work - in fact it typically logs a connect-timeout (followed by a successful retry) attempting to reach the broker. Subsequent Subscribed messages to the same Topic are received by the PLC (according to the log) but don't get processed - it's like it hangs.
If I process a different subscription I get the same behavior - one (usually with a timeout) PUBLISH and then it stops responding.
In order to fix this I've had to add a second Device that points to the same broker, and I've changed the SUBSCRIBE message to use the new device. Now everything works just fine, with no delays
It seems as though the device gets itself in a mess when I'm PUBLISHing within a loop that contains a SUBSCRIBE.
Andrew.
-
I've spent the past week banging my head against my monitor, trying to figure out why my PUBLISH messages wouldn't always get sent. Here's the code structure:
1. Stage with SUBSCRIBE for 4 subscriptions.
2. Each time the subscription receives a message I SGSET to a stage specific to the subscription and PUBLISH an appropriate message back to the broker, then I SGRST the stage.
What I have been finding is that the first PUBLISH takes a long time to work - in fact it typically logs a connect-timeout (followed by a successful retry) attempting to reach the broker. Subsequent Subscribed messages to the same Topic are received by the PLC (according to the log) but don't get processed - it's like it hangs.
If I process a different subscription I get the same behavior - one (usually with a timeout) PUBLISH and then it stops responding.
In order to fix this I've had to add a second Device that points to the same broker, and I've changed the SUBSCRIBE message to use the new device. Now everything works just fine, with no delays
It seems as though the device gets itself in a mess when I'm PUBLISHing within a loop that contains a SUBSCRIBE.
Andrew.
I'm definitely seeing the dropped queued PUBLISHes when the broker is shut down and gets restarted. I don't see any difference in that behavior with a second device though. I don't ever see drops if the broker is alive and connected.
-
I think I know what's happening in my case. I'm using $UTC as my data, and when I load the FIFO quickly I get the same value in there multiple times. It appears to be using the "only if value changed" option (which is the default) even in an event mode. When I make sure the data different every time, I get all of them every time.
A workaround to that is to put it in interval mode and select the publish every time option. DmD will complain about you doing it in a stage, but it will still work if you put it in a stage and transition out on the success bit.
The fix should be easy.
-
Hmm - the effect I'm seeing is very pronounced. I have all my program code blocks set to always yield at a yielding instruction - is it possible that that's causing the problem?
Also, I have PUBLISHes in two program blocks. Could that be adding to my misery?
-
Hmm - the effect I'm seeing is very pronounced. I have all my program code blocks set to always yield at a yielding instruction - is it possible that that's causing the problem?
Also, I have PUBLISHes in two program blocks. Could that be adding to my misery?
I'm happy to test whatever configuration you have.
I wouldn't have comm code in any block subject to yielding, but unless you are looping, nothing actually is.
Multiple blocks shouldn't be an issue. Nor should multiple instructions.