DEVWRITE, is it bugged or am I?

[OrionHE]

Is it supposed to say "(milliseconds)", because in my testing, it is milliseconds.

Also, Why do I get an email "success" if the timeout is too short? Logger reports timeout, but my email logic is sitting happy with the success bit set with a 20ms timeout going on. Meanwhile, no email is getting sent.

It seems that the system-configured @SMTP_Client can only be configured in seconds, so incredibly short timeouts (like 2ms) are not possible. But when using DEVWRITE to setup the SMTP_Client, the ultra-short values make it think it was successful.

[BobO]

Need to check when I'm back in the office, but I'm 95% sure this has been reported and fixed.

And yes, it's us, not you.

And no, we're not breaking up with you.

[BobO]

It's milliseconds internally to the driver layer and the DEVWRITE property was definitely intended to be seconds, but that was the bug...there was no conversion from seconds to milliseconds. As I thought, it has already been fixed and should be correct in the released BRX code, but I don't think we've released H2-DM1E or T1H-DM1E code since it's been fixed. It'll be correct in firmware that ships with DmD 2.1, currently planned for September.

[OrionHE]

Ok, so once I update firmware, my program will have to change from 20000 to 20. Setting a reminder now. Thanks for the update.

[BobO]

Ok, so once I update firmware, my program will have to change from 20000 to 20. Setting a reminder now. Thanks for the update.

You can change it to 20 seconds in the SysConfig. Does it need a runtime change?

[OrionHE]

That brings me to another topic, that may warrant a new thread.

I started using DEVWRITE as a solution to send emails from one of our units in Washington State. It uses the same exact program as nearly a dozen California-based units. All of the California units can, and do, send emails daily. Yet, the one in Washington doesn't.

I figured if I could write new parameters into the SMTP_Client device then I could experiment with different options like SMTP port. I did not count on the seconds to milliseconds bug and wasted a day and a half thinking it was me and trying other solutions. Now that I know it's milliseconds I'm back to testing and using various SMTP ports I still can't send emails from that WA unit, though I can connect to it via VPN.

Technically, no I don't need to change it at runtime. But I am changing it at runtime to fully test the DEVWRITE function.

[BobO]

I figured if I could write new parameters into the SMTP_Client device then I could experiment with different options like SMTP port. I did not count on the seconds to milliseconds bug and wasted a day and a half thinking it was me and trying other solutions. Now that I know it's milliseconds I'm back to testing and using various SMTP ports I still can't send emails from that WA unit, though I can connect to it via VPN.

I am very sorry this resulted in lost time. That's very frustrating.

DEVREAD and DEVWRITE are basically back doors to access properties internal to devices. We tend to use them as the fall back when we need to change something at runtime, but it doesn't make sense to dedicate an instruction. In the interest of completeness, we've tried to throw everything in there that makes sense (even when we really only cared about one or two properties), but being a back door that accesses things that are usually not needed, they haven't been tested as exhaustively as the instructions themselves.

The SMTP timeout property has been broken since the release of the H2-DM1E back in 2012, but we just got wind of it recently. There was some internal discussion as to whether we should keep it is milliseconds and change the description, or make it work like it was always intended. Since we only heard one report in 4 years, we felt that virtually nobody was using it, so we decided to make it work as intended, knowing that worst case timeouts would get ridiculously long, but that it wouldn't break normal operation.

[BobO]

...I still can't send emails from that WA unit...

Turn on $EnableMsgDump (ST36) and run DMLogger on the same network as the PLC. That will give you some good insight into what is going wrong.

[OrionHE]

I wished I had this ability over VPN. It's very helpful when I can use it. Thanks, BobO.

[BobO]

I wished I had this ability over VPN. It's very helpful when I can use it. Thanks, BobO.

The messages that post to DMLogger are also being written to the MSG or ERR string heap items. You could write a small bit of code to push the current value of MSG into a block of user strings any time it changes. It might not catch them all, but should get most, and you should be able to access them via VPN.

[OrionHE]

Boom! That's something I can use.

[BobO]

Boom! That's something I can use.

If you keep digging through that big pile of poop, you'll find the pony eventually!

[OrionHE]

Interestingly, I'm able to use a delta contact on every other type of tag besides MSG. I can read MSG into a string, but now I just want to know the technical reason why delta doesn't work on MSG.

[BobO]

Interestingly, I'm able to use a delta contact on every other type of tag besides MSG. I can read MSG into a string, but now I just want to know the technical reason why delta doesn't work on MSG.

Delta works on all numerical variables and structure fields. MSG is an entire structure, like a timer or counter or PID structure. Delta works on MSG.Length, but not the entire structure.

[OrionHE]

Thanks you.