Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Mike Nash on August 19, 2016, 07:40:46 PM
-
I need to experiment with getting a Do-more to talk to an ASCII RS422 device.
I have an F2-UNICON which is designed to work with the pinout such as found on the D0-05 Port 2.
I have also found the pinout changes quite a bit between the H2-DM1(E), the H2-SERIO(-4), the D0-05 Port 1 and the D0-05 Port 2. I think the cable that comes with the F2-UNICON may have both pins 1 and 6 tied together on the the F2-UNICON, but I have not verified this.
Which of these ports/devices can it work with?
Have I killed any plugging it into a D0-06 Com 1 or an H2-DM1E Port 2 before I realized these differences?
I was only wanting to work on the programming and do not intend to use the F2-UNICON if we do this job. And of course it is now the weekend and I don't have these with me.
-
After looking into the crypt of RS232 mysteries, I think I have convinced myself that Pin 6 of the Do-more Port 2 is safe since it is an input. Also, I can set it to ignore CTS.
Pin 5 of the D0-05/D0-06 Port 1 is safe since that is an input on the F2-UNICON for RTS from the PLC side.
And if I had an H2-SERIO, Pin 2 is safe because it is an input and there should be no power to the F2-UNICON from it. If the F2-UNICON were provided 5V from the terminal strip, the CTS on the SERIO shouldn't mind.
But we will probably just use an H2-SERIO-4 and skip any converter. There probably wouldn't be more than 3 feet of cable involved.
-
??? Digging a little deeper online and it looks like 232 has been modified so many times since 1962 that the signals are "whatever" anyone wants. I hope RTS isn't "Release The Smoke!" on my stuff.
It is but it isn't but it might be yet.
-
The pinouts were chosen with the intention of you not burning anything up inadvertently, but when you put power on a comm cable, stuff happens. Sorry for any confusion.
-
No need for sorrow. :) To be fair, the info I have been able to find only shows the F2-UNICON to be compatible with the D2-240 bottom port and D0-05 Port 2. But if the cable fits... So I did.
I suspect that it will work. I just realized when I was playing around in a hurry that it might have been a mistake.
The 422 device I want to connect to was in a fire at one time and isn't precisely what I need to talk to (same brand, different function), but does work and will allow me to get Do-more ASCII working to prove it out. I wrote a QB45 program nearly 22 years ago that could talk to them. The old laptop I had could even talk to the 422 port with it's 232 port, though later ones didn't work so well. Back to those variable standards.
-
Just a follow up. After I finally realized the F2-UNICON 422 terminals are
+ - - + instead of
+ - + - like I assumed...
I got the Do-more to work very well with it on the built-in serial port.
-
Awesome.
-
Follow up part 2.
I have finally used Stage programming for something, even if it is just testing. The ASCII comms using StreamIn and StreamOut is finally something that seemed suitable and it is very, very clean. I still won't find it real useful for most of the things I do, but I like it quite well for this.
If I had a need to only occasionally send a parameter to a device, would a task work for this, or does it need to be a program?
Second question, can I change the serial port settings on-the-fly (such as auto setup of comms looking for a response?)
-
If I had a need to only occasionally send a parameter to a device, would a task work for this, or does it need to be a program?
You need to use a program.
A task is intended to only be active for a single scan (this can be bypassed using a YIELD or a looping instruction), and therefore is not intended to run multi-scan instructions.
Second question, can I change the serial port settings on-the-fly (such as auto setup of comms looking for a response?)
This can be done using DEVWRITE, but (as I understand it) this is writing to the Do-more flash which has a finite number of writes.
-
Thanks plcnut,
I was thinking more along the lines of SETUPSER which does allow me to set the communications parameters, and I have gotten it to change them to what I needed after I set the serial port intentionally incorrectly in System Configuration. I can always play with it more, but it was irksome to get all my ducks lined up to be sure I had the wrong mode before enabling SETUPSER so I figured I would ask. I was wondering if an Auto Configure would be feasible in ladder. I would probably never use it but...
I have used tasks and programs previously, but the tasks were run once then quit, even if it did take over a minute to complete all the For-Next loops. :)
-
OK, SETUPSER can indeed be used to Auto Configure the serial port to detect a device's settings. Caveat? No variables in SETUPSER so it requires quite a number of steps to test all possibilities.
I have a question regarding handling programs and stages and maybe I should start a new topic, but I'm not going to.
I have a program called SerialComs, with a number of stages and each just calls the next unless there is an error. This is the one that will just run all the time we'll say.
I have another program called AutoConfig that has all the stages to go through changing settings, streaming out and in and checking for success.
If I want to stop running SerialComs and run AutoConfig, I can't seem to figure how to do that cleanly. This is where the stages seem to stump me. Most things I have tried cause a warning or will stop the subprogram from functioning even when it is "Run". Any suggestions?
-
HALT in Main appears to be a bad choice if the subprogram is running communications. EXIT from within the subprogram works well, but I am not sure how to handle it cleanly where stages are involved. If I have to wait until it gets to a stage I know it must get to, or an error handler then two EXITs will work. But in a case where I may not have a stage I will always get to, or may need to get out of before completion, what should I be using?
If I don't HALT SerialComs before trying to run AutoConfig, it may just jump back into SerialComs instead.
-
So I dug around and found a cryptic comment BobO made "If you really don't want to see it, just clear it from ladder code." regarding Driver Error ST143 http://forum.hosteng.com/index.php/topic,1670.msg14118.html#msg14118 (http://forum.hosteng.com/index.php/topic,1670.msg14118.html#msg14118)
Since I am generating errors due to STREAMIN timeouts while hunting for valid comm settings, I found I could RST ST143 once I got a successful response. But I still have all the "Operation timed out in STREAMIN @00000204 (STREAMIN at AutoConfig@76)" errors showing in the System Status. I can MEMCLEAR LastERR0-7 but that doesn't keep those errors out of the Status. I know these will happen and would only want to clear or prevent them at a known event. Is there a way to do this?
-
I'm at ADC finishing up some critical testing of the new hardware, and will be back in the office tomorrow evening. Will speak to this when I'm not posting from a cell phone.
-
Since I am generating errors due to STREAMIN timeouts while hunting for valid comm settings, I found I could RST ST143 once I got a successful response. But I still have all the "Operation timed out in STREAMIN @00000204 (STREAMIN at AutoConfig@76)" errors showing in the System Status. I can MEMCLEAR LastERR0-7 but that doesn't keep those errors out of the Status. I know these will happen and would only want to clear or prevent them at a known event. Is there a way to do this?
Maybe each time that you have a failure, you could RST ST143, and MEMCLEAR LastERR0. This would only clear the message that was produced by that specific error.
-
The RST ST143 works great. The warning shows at the bottom of DmD then turns off when I reset it. The LastERR0-7 MEMCLEAR does clear the tags, just not the System Status messages.
It's pretty neat having the Do-more hunt down and find the communications settings when I change them on the fly at the device. If I could use variables for the parameters of SETUPSER that would make the code way easier/neater. There are quite a few possible combinations with baud rate, data bits, parity and stop bits. There are only 4 baud rates that overlap on this. The device is 300-9600 and Do-more is 1200-115200. So that is 4*2*3*2 = 48 SETUPSER instructions plus associated write and reads.
But even neater is that this part was just a play project. Communications I will need, automatic configuration was more of an "I wonder if.."
BobO, I hope the hardware testing is going well!
-
If you use DEVWRITE then you can use a variable to control each of the serial port settings. The SETUPSER is nice, but DEVWRITE offers more flexibility.
-
If you use DEVWRITE then you can use a variable to control each of the serial port settings. The SETUPSER is nice, but DEVWRITE offers more flexibility.
Yes, I see, thanks. That also answers my unasked question of how to read the current serial port settings (DEVREAD).
So I guess the question is whether I would burn through any non-volatile memory write life doing this too often in a worst case scenario.
-
If I had a need to only occasionally send a parameter to a device, would a task work for this, or does it need to be a program?
You need to use a program.
A task is intended to only be active for a single scan (this can be bypassed using a YIELD or a looping instruction), and therefore is not intended to run multi-scan instructions.
This is true for multi-scan instructions, but DEVREAD/DEVWRITE are not multi-scan, so technically you could put them in a Task.
Second question, can I change the serial port settings on-the-fly (such as auto setup of comms looking for a response?)
This can be done using DEVWRITE, but (as I understand it) this is writing to the Do-more flash which has a finite number of writes.
DEVREAD and DEVWRITE are just driver property accessors, so they don't write to flash.
-
DEVREAD and DEVWRITE are just driver property accessors, so they don't write to flash.
Fantastic, thanks! That explains why nothing was mentioned about write limits anywhere.
"accessors" - I learned a new word today. :) OK, I probably haven't "learned" it yet, but it's a start.
-
DEVREAD and DEVWRITE are just driver property accessors, so they don't write to flash.
Fantastic, thanks! That explains why nothing was mentioned about write limits anywhere.
"accessors" - I learned a new word today. :) OK, I probably haven't "learned" it yet, but it's a start.
Spell check isn't happy with the word 'accessor', but it is a common term for a method that gets/sets a property in a class. We knew that we would want to tweak driver internals without using a dedicated instruction for each, so we built a general purpose instruction for reading and writing them. The nice part is that we can come back years later and add new accessors with virtually no development effort, which makes it far easier to say 'yes' to customer requests. We've already done several in the SMTP client device, and it wasn't hard to justify.
-
It turns out I have only 4 baud rates that are compatible and only 3 possible data bit, parity, stop bit combinations for a total of 12 possibilities. It further turns out 8, none, 1 stop and 8, none, 2 stop bits are interchangeable for what I am doing (I got the correct response at 1 stop even if the device is set for 2 stop bits.)
What this meant was that the SETUPSER was quicker for the format and DEVWRITE was nicer for the baud rate.
(Hmm, as an aside, DmD 1.4.3 really doesn't like to open when Firefox has this forum open, very strange.)
[So I think the DmD issue may be more to do with not having the VPN connected when the last project opened was using it? Gotta check that more, but with the VPN connected first DmD works as usual. This even though I was only planning to do an offline check.]
I also discovered that $03 for the 12th character is not a solid way of determining if the response was good. If the port settings are wrong I can get this where it should never be. But if I allow 12 bytes to also be a completion, I may still be getting a bad response. I do know I should get @ as the 4th character for this response test. So does anyone have a really nifty bit of code for checking these 4 conditions are all true?
A) starts with $02
B) @ is 4th ASCII character ($40)
C) ends with $03
D) has a length of 12 characters inclusive.
I currently have $03 terminating the STREAMIN, STRSUB to get the 4th character (offset 3), STRCMP to see if it is @ and no check for $02 or length of 12.
A plcnut post reminded me of SS0.len so that will be easy to add. Gotta go, about to lose utilities.
I did a little more digging, STRGETB lets me put those 12 characters into a "buffer" that then lets me do simple = contacts on length, 1st, 4th and 12th characters as expected. This is closer to what I had in mind from BASIC days with LEFT$, MID$, RIGHT$ = those expected characters.
Still open for for more elegant solutions!
I haven't lost communications with it yet even though I have been randomly changing the device's port settings from a Data View via Do-more's serial port and they are both at the office and I am at home. Do-more has found the settings each time just fine. Not bad as long as I don't try to set below 1200 baud. ;)