Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: sgsims on August 31, 2016, 12:40:21 AM
-
It looks like every time the Network Timeout limit is reached the Error Bit is Set High and the ST143 System Bit is set high. Ok fair enough...I put some stages to JMP to on ERROR. But what do I do about the pesky ST143 bit that goes high? Should I simply add some logic to take the ST143 bit low? Is there something else I should be doing as a result of the ST143 bit going high?
In my case the Network Timeout limit is being reached because the .inqueue buffer is empty or 0 if you look in the data view. I was using the error bit to tell me if the external devise, a scanner in my case, never sent me a code as expected.
Are there any other ST Error bits I need to worry about with the STREAMIN instruction?
-
I rarely use the timeout as a part of the protocol itself, preferring instead to use .InQueue to monitor for the arrival of the expected data, then call STREAMIN to read it. If you do choose to use the timeout, then yes, you'll need to clear any error indications, but there shouldn't be any others though.
-
Thanks Bob...I guess that .inqueue monitoring idea was staring me in the face the whole time...I'll definitely utilize that into my program.
In general how should I be dealing with any warning or error bits that go high, I'm talking about any error bits not just the ST143 I mentioned. Once the plc is commissioned and at the customer site those bits would just go high and stay high.
-
They are all writable and are there for your benefit/pleasure/enlightenment/etc, so feel free to clear any/all as part of your exception handling. We don't really know what constitutes a critical failure for your app, so we err on the side of informing and leaving you to determine the importance of the event. Immediately after the instruction terminates with an Error condition, you can check the top of the error stack (DST30...I think) to see what the error was. If expected, clear and go...if not, give appropriate warning to operator.
-
Thanks Bob...I'll explore the error stack..and then of course more questions:) I really appreciate the help..BTW I'm really enjoying the Do-More way of Programming...took some time to get used to the new way of doing things but I am really pleased so far.
-
Thanks Bob...I'll explore the error stack..and then of course more questions:) I really appreciate the help..BTW I'm really enjoying the Do-More way of Programming...took some time to get used to the new way of doing things but I am really pleased so far.
We recognize that Do-more is different than most PLCs, and that is why we try to monitor the forum pretty aggressively. We have also seen this same thing play out dozens of times...once you see the method behind the madness, Do-more becomes quite the power tool to you. Even though I've heard it many, many times, it still makes me smile every time I hear it. And the upcoming new hardware and the associated DmD 2.0 is going to raise the bar even higher! Stay tuned!