Serial data from 1 output to1 PLC input

todster said:
It aint the math that sucks, I think it's the old age creaping up.
 
Age is a state of mind, and I plan to live forever (or die trying).
 
(Seriously, not sure how old you are - but I started programming using punch cards and progressed to ASR33 teletypes and punched paper tapes!)
 
rossw said:
Age is a state of mind, and I plan to live forever (or die trying).
Unfortunately that's the part I'm missing. I'm number and memory challenged. The US govt. says it has nothing to do with Desert Storm. I didn't trust the Govt. then and I don't now. I probably will live forever, I'll just be making a lot of new friends everyday.
I've got my ULN2003A dips today and I downloaded serial ports complete, so now I have to put an interface together and start playing with the PLC and the W/C. Time to learn and forget.
Serial ports complete for those that want it.  http://www.8051projects.net/e107_files/public/1347193247_22104_FT57363_serial-port-complete-com-ports-usb-virtual-com-ports-and-ports-for-embedded-systems-complete-guides-series.9781931448062.31506.pdf
 
CAI_Support said:
Upcoming WebControl32 will have two serial ports, but not for communication between devices and WC, rather is pass through to the remote host PC or Linux.
We may change that to have one RS232 as pass through, the other one for local control. But not sure we understand the logic talking to Allen Bradley PLC.
If you can test it out between a PC and your AB PLC, then publish the exact communication strings, we may considerit later, when our engineers have chance to work on that.
This is the AB manual for DF1 serial comm. I'm not an expert on it by any means.   http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1770-rm516_-en-p.pdf   A typed read and write from pages 7-28 to 7-30. The PLC I use is SLC5/04
 
todster said:
This is the AB manual for DF1 serial comm. I'm not an expert on it by any means.   http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1770-rm516_-en-p.pdf   A typed read and write from pages 7-28 to 7-30. The PLC I use is SLC5/04
That link you provided is error 404, page not exist.  We hope that someone would tell us: this is the string you send, that is the reply you got.  If we have to follow AB manual to implement everything, that might be too much to fit on our chip.  We probably could implement subset of of that AB DeviceNet.  I thought you just want WebControl becoming additional I/O to the AB PLC, am I correct?
 
Ross, when the date is stored in a var, is this also how you extract the date from the string?
I'm also considering buying another module for the remote I/O on my PLC (usually $10 on ebay) and using the W/C only as an analog interface and passing the info to the PLC in parallel across all eight. I can also use the 8 in from the PLC the same way to request specific info. The analog for PLC is $200 minimum and that would be if I were able to get lucky sniping it on Ebay, so the <$40 for the W/C is lucrative. My 1st question in this case would be, would it be better to send as BCD, octal, or just 8 bits? The resolution on the W/C is only 10 bits anyways.
 
CAI_Support said:
That link you provided is error 404, page not exist.  We hope that someone would tell us: this is the string you send, that is the reply you got.  If we have to follow AB manual to implement everything, that might be too much to fit on our chip.  We probably could implement subset of of that AB DeviceNet.  I thought you just want WebControl becoming additional I/O to the AB PLC, am I correct?
What I want is to harness the W/C for the analog and temps. Using the serial ports to get and place data in the correct locations. The link worked for me just as few minutes ago.
http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1770-rm516_-en-p.pdf
 
I/O is cheap. The analog for temps etc is not.
I'm not sure how the AB DF1 protocol works and how it would communicate to the W/C. I will try and see if I can capture the serial port to it. What have you found to be the best port capture program?
 
todster said:
Ross, when the date is stored in a var, is this also how you extract the date from the string?
I'm also considering buying another module for the remote I/O on my PLC (usually $10 on ebay) and using the W/C only as an analog interface and passing the info to the PLC in parallel across all eight. I can also use the 8 in from the PLC the same way to request specific info. The analog for PLC is $200 minimum and that would be if I were able to get lucky sniping it on Ebay, so the <$40 for the W/C is lucrative. My 1st question in this case would be, would it be better to send as BCD, octal, or just 8 bits? The resolution on the W/C is only 10 bits anyways.
 
 
I only used the time as something relevant to test, as I could see it changing to be sure the code worked. (it did, first time - always nice!)
 
By using an arbitary number of bits, you could send 8, 9, 10, 16, whatever. Be aware that the more bits you send, the greater the chance of clock slip and errors in the data.
I have not observed any problems with sending 17 bits at 200ms/bit. I'm about to modify my local code here to send a parity bit as a partial check of data integrity.
 
By writing it as a subroutine, I plan to use it in my own situation to send multiple words for different things (in the circuit I posted, I will send commands TO the downrange devices to tell them where to position, and read data back FROM them for the X/Y/Z angles and actuator current.
 
The parity is along the lines of what I was thinking. I wasn't sure how to do a mod function to test for odd or even yet. If I just use it as parallel the 100ms timings become a little less of an issue. Strobe send 8, move the next 1/2 word in. strobe and send 8 parallel bits.
 
todster said:
The parity is along the lines of what I was thinking. I wasn't sure how to do a mod function to test for odd or even yet. If I just use it as parallel the 100ms timings become a little less of an issue. Strobe send 8, move the next 1/2 word in. strobe and send 8 parallel bits.
 
Parity isn't terribly difficult.
As for parallel, I'd strongly suggest doing it in nybbles. You only have 8 bits, so sending strobe will be difficult unless you do something funky like letting the other end dictate which part of the word you're sending - and even then you still have no handshake to tell it when you've presented the data etc.
 
Many years ago I wrote some software for a very bottom-of-the-range siemens for a bakery. It had to read a bunch of thumbwheel switches. Siemens said the unit simply couldn't do it, and there was no IO card to add the functionality. It was all programmed in ladder too, just to add to the mess.
 
I worked out a way to do it that allowed it to read (from memory) all 3 banks of 3-digit thumbwheels. It earned me an all-expenses-paid trip the Siemens office in Melbourne to explain how I did it :)  I think they were impressed ;)
 
So the rule here is: don't be constrained by the "conventional thinking" box. Let your mind fully explore the options. Throwing money at the problem is not always the right answer, and is rarely the only answer!
 
I'm going to have 8 bits both ways. The PLC will request the data and will wait for the W/C to send. I can do nibbles both ways. The thing I like with the PLC I have is that it runs its logic 1st then sets the outputs. It is sequential in operation and flipflops etc can be predicted and the logic flow taken advantage of. The PLC also has advanced math. If I use the webset feature I could have the PLC controlling the other W/C's as well and receiving input from others as well. Ladder is easy for me. I also like to do it in structured text because I can do a lot of the logic and I/O with a spreadsheet.
I'm also not one to stand on tippy toe  trying to peer out of the box. I prefer to cut a hole in the side and get a better view.
Sounds like an older Siemens S7 brick.
 
" I have is that it runs its logic 1st then sets the outputs. It is sequential in operation and flipflops etc can be predicted and the logic flow taken advantage of. The PLC also has advanced math."

Surely AB PLC is a powerful device. Now, what can we do to make it simpler for you to communicate between the AB and WebControl?  LIttle processor on WebControl does not have advanced math funciton. But we can implement some additional math function in PLC logic, if we know which math must to have.  In the 3.02.16c firmware we already have trignometry functions for PLC logic to use.
 
For the time being, I just want to initiate comms between the 2. If the W32 had the ability to place into the PLC memory locations I'd order 1 now. The serial connection to the plc is fussy and I haven't found any freeware that lets me spy and log. You get 1 or the other. Once I can log the comm I can send it to you to see if it can be enabled on the W32.
 
Before I can go much much further I need to convert 24vdc to 5vdc from plc to W/C and risk burning up either. Any suggestions? I have SSR's but they are Triacs. I guess I could use the 120VAC modules  ( got lots of them). It just seems a little retarded that way.
 
todster said:
Before I can go much much further I need to convert 24vdc to 5vdc from plc to W/C and risk burning up either. Any suggestions? I have SSR's but they are Triacs. I guess I could use the 120VAC modules  ( got lots of them). It just seems a little retarded that way.
 
Given the fairly low speeds involved, I'd use open-collector drive, either in a chip (like a ULN2003) or more likely using discrete components like BC337.
BC337 is perhaps overkill - Ic(max) is 800mA, but they're a robust and inexpensive transistor.
If you used a 4K7 base resistor you'll have more than enough drive even from the webcontrol board.
Ground the emitter and pull the collector to a +24V via 2K2 should pull the PLC inputs high. The collector resistors are going to pass about 11mA each and dissipate just over 1/4 watt, so use half watt resistors.
 
Going the other way, you could use the same thing, but I'd use a higher base resistor. Perhaps 10K. Use 1K collector pull-up resistors to +5 v for the webcontrol inputs.
Only downside with this is that your levels will be inverted - that is, you turn a WC output ON (high) will turn the transistor on, and ground the input to the PLC. You could perhaps mitigate this with input and output inversion on the WC board.
 
A somewhat more ugly solution for the PLC->WebControl would be to use a 4V7 zener across the webcontrol board input, and a 4K7 series resistor to the PLC output. This resistor will pass 5mA, and dissipate about 100mW. When the PLC output is low or open, the WC board will see a '0', when the PLC output is 24V the zener will clamp it to nominally 4.7V. The advantage of this is the non-inverting nature.
 
Or of course, optocouplers. They're available in 1, 2, 4 and 8 devices per package, and provide you with galvanic isolation. Watch the LED current requirements though, as the webcontrol board may not be able to drive 8 of them at once.
 
My WebTerminal board has space to install pullup or pulldown resistors which could easily be used for the zener diodes, but you'd have to mount the series resistors external to the board. (Perhaps I should add that option for version 3?!)
 
Edit: Diagram - replicate as many times as needed (for each channel)
WC-PLC-Interface.gif
 
Back
Top