martinav (Customer) asked a question.
I have this rs232 command set to move to the next stage whether it works or not. However, it wont move. Locks up every time. Whats the deal? Inc is clicking away, but nothing else seems to be happening.
It appears both success and error are false, therefore, it will not move to the next stage until one of these goes true.
Not sure if this is needed, however, you have no conditional contact on the input rung of the instruction. The gray triangle at the right end of the input leg indicates the input is edge-triggered, meaning this instruction will execute each time the input logic transitions from OFF to ON. See help topic DMD0304.
The STREAMOUT will run properly with just being tied to the power rail after a SG instruction. The STREAMOUT instruction's "termination" behavior clears the edge states, so that the next time (or first time) you enter S1, it will trigger as expected on that first scan entering the SG. (first rung of a code-block, first rung after any SG or looping instruction, all have their Top of Bool Stack set to 1).
Note that the INC box will continue to count (which I am guessing is what's happening since it's a huge number). At this point, if it is behaving as OP describes, t should behave like a "scan counter".
This is an interesting point. Please dont take this as argumentative. I do a lot of things here from the advice or 'copying' of those that are very established on youtube, etc. Using stage like this, and no c bits, using the entry to the stage as triggered, and leving the stage as disconnected. I think this is the right way to view this??
Yes, the inc in S1 is ticking away. THe instruction should have completed or errored, but neither is the case.
This is not a new program, btw. I am just re-structuring it from what I have learned for my first go-around. I'm adding a thermal condition (and added a BX-4UT4TD2) which is working tremendously well. My thermal reading worked first time out of the box. Tremendously simple, compared to RS232.
Anywho, I have a couple of continually looping programs. One to scan the RS232 port for readings, then another that clears the gauge and resets it to zero. The interesting point, is that I had these two programs running on a three day test, and it never hiccuped once. However, now, the two programs do are not able to execute together. The interesting point is, I would thing the reading program should be HALT'ed before running the clear program. It makes sense that there might be some conflit doing read commands every second at the same time I'm running clear commands to the same gauge from a different program. I did question this before, but it worked fine, so I wasnt going to argue, and I just went with it. Well, now it seems that BOTH the read and the clear programs are held up. One is sending a clear command, the other a read command. BOth stuck in that stage. I find it odd that this never happened once when I was developing the first program, and ran great the entire test. So, my plan... is to HALT the read program, then run the clear program, then re-run the read program after clear is complete. Make sense??
By the way, these programs worked great for my first test. I am only messing with them because they quit working.
Clear Program:
Read Program:
You are likely getting device contention. I'm guessing the STREAMOUT is waiting for the device to be unlocked. Pull up the Device View (Devices button on the toolbar) and see what is going on with @IntSerial.
BTW, HALT is not the preferred way to stop a program block. That really is an exception. The preferred way is EXIT from within the program, and ideally, only called after devices have finished their work. It should hurt anything, but it may be forcing abnormal termination of a device function. Think of it like unplugging your PC rather than using the shutdown function.
Yea, I got that indication that it wasnt preferred, from the warning message. In fact, it worked to make the clear program work, however, restarting the read program its still broke. However, the commands in the clear program gets the proper acknowledgement from the device. I do see a locked command when the read program restarts:
I will attempt an exit in lieu of the HALT.
Well.. Seems the adding of the module or something in the changing of my setup has affected the completion trigger of the STREAMOUT... I simply checked on the timeout after 100ms, and its all good now.
I'm not kidding when I say this has taken in the neighborhood of 10hours of time to find out, and I made a LOT of unnecessary changes due to it.
I am genuinely sorry it took you that long.
You have STREAMIN configured to wait *forever* until the expected data is there, it's doing what you asked. All Do-more devices are internally interlocked, so when one instruction is using the device, others will wait until he's done.
You may have forgotten, but I suggested that you use the .InQueue structure member to determine whether data was queued before making the STREAMIN call. That is still a good plan. In the end, you either need to be sure that the call will succeed without a timeout, or you need to provide one.
Please hear this in a positive tone, but if you spent 10 hours chasing a problem, doesn't it make sense that maybe some of that time would be best spent trying to understand all of the options associated with an instruction you are using?
You're making a protocol. You send bytes. You wait for a reply. How long? As long as it takes to determine that you didn't get one. That will be a function of the data rate and the latency of your device. I have no idea what the answer is, but for Modbus RTU, we generally have timeouts in the 1 second range.
So again, you are implementing a protocol. You need to be concerned with how everything works right, but you also need to be concerned with how everything works wrong. Bytes don't arrive, bytes arrive corrupted, things get disconnected, etc. You need to be asking these questions at every step of the process. STREAMIN will fail at times. How are you handling that?
There is a system structure for the @IntSerial device named IntSerial. It has four data members, IntSerial.InQueue in one of those. It will show you the number of bytes queued into @IntSerial. From the stage that you call STREAMOUT to start the transaction, jump to a stage where you wait for data to show up in the port. I usually add a timeout to that stage. Once I have as much data as I expect in the reply, I then jump to a STREAMIN stage where I read the data, and then a stage where I process the data. The attached image shows the logic I generally use in the wait stage.
Finally, your device response may not be a known length. If so, you may not want to use the logic I'm showing and instead use the timeout in the STREAMIN. You might still use what I'm showing, but only wait for the minimum size you know you will get...if your response is 5 to 7 bytes, wait for 5, and then add a timer to allow for the last 2 bytes before jumping to the STREAMIN stage. It is also possible that the delimiter got corrupted, so you probably need a timeout in STREAMIN to deal with that possibility, even if you use the external timeout. Again, you are just dealing with what happens when things work right, but you have to ask what could possibly go wrong at every step and handle that too. It isn't hard, but it does take thought and planning, and things won't work right when you aren't doing it right. You said everything was working right, and then didn't. Right. That's exactly what happens when you haven't planned for the failures.