Serialization of CQC SMS Serial Interface Driver

[Dean Roddey]

If the driver itself remembers the last time it sent, it can provide that capability by just waiting for the remaining amount of time if the last one was within the timeout. I guess I could make the timeout a driver prompt so you can adjust if you want.

[Dean Roddey]

Here is another one to try. This one is considerably more complex a change to do by eye, but hopefully it's right. So the deal is that the Busy field is still there. When you send a message it sets the busy field and sets a time stamp for then plus 5 seconds. The poll will then watch for that time to expire and then it will clear the Busy flag. That way we don't have the driver blocking for any longer than needed to send the message, and the Busy field can be used to limit the rate.

If you try to send while the Busy field is set, it will be rejected. So import, then do a reconfig on the driver to pick up the changes.

[gReatAutomation]

Thanks. I'll give it a try.

[gReatAutomation]

This does not work. The driver goes from OK to Red, to OK, to RED.

The "Some fields of this driver got no initial values." is coming from the SMS driver.

[Dean Roddey]

OK, I got something wrong. I can't really realistically run it because it will just time out trying to talk to the hardware, so I was sort of having to do it by eye. You might have to set up the remote port server for me so that I can actually run it. I don't need to send any messages most likely.

If you put it into verbose mode and check the logs it may give us a hint that would let me fix it without having to do that.

[gReatAutomation]

Here are logs with driver in debug mode.

[Dean Roddey]

Hmmm... Something was going way too fast. It logged a lot of messages all in a second, then went off line. I'll have to see if I can figure that out.

[Dean Roddey]

OK, the dangers of doing stuff by eye. He had a HeartBeat flag in the poll that he would set to true if he got a response from the modem. I needed to now use the Poll for multiple things, so I speeded up the poll and use time stamps to do the different things. So now his code to get that heartbeat flag wasn't always being called. So the first time it called the poll method, that would be false and his logic would say, oh well no response so recycling the connection.

[gReatAutomation]

OK, the dangers of doing stuff by eye. He had a HeartBeat flag in the poll that he would set to true if he got a response from the modem. I needed to now use the Poll for multiple things, so I speeded up the poll and use time stamps to do the different things. So now his code to get that heartbeat flag wasn't always being called. So the first time it called the poll method, that would be false and his logic would say, oh well no response so recycling the connection.

Thanks.. What was changed, in layman's terms 

[Dean Roddey]

It's just that the driver itself now imposes the delay, so you don't have to. It will return as soon as it has sent the message, but it sets the Busy field and will keep it set for the next 5 seconds. If you try to send while the Busy field is set, it will return an error. So continue to use the WaitFieldValue() thing to wait for it not to be busy.

Of course now that the delays are in the driver, you can use that to some advantage in some cases. If you have other things to do in the action, interweave some of that between msg sends, then wait for the Busy field, send a message, do some other things, wait for the Busy field, etc...