Serial data from 1 output to1 PLC input

The current is what I'm focusing on keeping to a minimum. I already have the ULN2003 for the 5V to 24V. Now I need the 24V-5V. I've pretty much figured the zener route as the most simpe and cost effective way to do this. Thanks for the ideas Ross. I think I'll try my hand at PCB's and make my own. If I had the time and wasn't learning so many other things, I have an open source DF1 driver coded in VB. I could develop a custom app to referee between the DF1 and the W/C. I just  lack the experience with VB and the time to learn it. I want a couple of your boards but the shipping would be more than the boards.
I'm going to use 8 bit parallel both ways so timing won't be an issue. Each unit will send a request and the other will respond with the requested info.
My current output from the 24vdc card isn't a big issue, I just haven't found an opto coupler and example circuit that handles 24vdc in and 5 out. Although I suppose I could use the zener and resistor on the 24vdc, it just adds a lot of baggage.
 
todster said:
I want a couple of your boards but the shipping would be more than the boards.
 
If I can keep the weight down to under 50 grams, and the thickness to under 20mm packed, the postage is cheap - around $2.50.
 
If you can solder, they're a no-brainer. I can JUST fit two "long" kits in the weight.
 
If anyone is still interested in this - I've adapted my code to do parity generation and checking.
I'm currently testing at a mere 50 milliseconds per bit. I know this is way below what CAI advise for timing, but I wanted to see just how much margin it has.
 
Currently sending 17 data bits, a modified start-bit and one parity bit (so thats 18 "information" bits) in a little under 1 second, serially, with 26% showing parity error.

Just changed to 200ms/bit - will leave it run a while to get a decent sample, but currently seeing 0% parity errors.
 
EDIT: Updated. Now after  >500 transmissions, just under 1% errors indicated.
 
How much were the kits? Paypal? I'll be wanting 2. I bought a crap load of resistors, transistors,more resistors and some zeners. I'll experiment and see which fits the ticket best. I won't have the parts for awhile but I'm going to start working on the W/C to PLC soon. I'd be interested in seeing the latest you've created for the serial.  I'm real curious as to how you're going to manage the id for the devices. It would be nice if we could have a priority interrupt for an input and an output. On the newer firmwares we have the counter function. Couldn't the counter be harnessed here to speed up the xfer? That is provided it isn't still bound by the 100ms limitation which wouldn't make sense if we are using it for a counter.
 
todster said:
How much were the kits? Paypal? I'll be wanting 2. I bought a crap load of resistors, transistors,more resistors and some zeners. I'll experiment and see which fits the ticket best. I won't have the parts for awhile but I'm going to start working on the W/C to PLC soon. I'd be interested in seeing the latest you've created for the serial.  I'm real curious as to how you're going to manage the id for the devices. It would be nice if we could have a priority interrupt for an input and an output. On the newer firmwares we have the counter function. Couldn't the counter be harnessed here to speed up the xfer? That is provided it isn't still bound by the 100ms limitation which wouldn't make sense if we are using it for a counter.
I'll send you a PM re kits.
I considered using the counter for some sort of comms, but there wasn't anything it could do better, really.
I could have sent a series of rapid pulses, but in my particular application, the length of cable and capacitance would prevent high bitrates anyway, and sending serial allows me to send vary large numbers (16 bits = 65535, double that for every extra bit!) with only small incremental time penalties.
As for IDs, my plan is to send a 4-bit address field.
I can send a broadcast which ALL my hosts will listen to
or I can send a single address and thereby address one of 15 hosts individually.
In my application, thats fine. I send a broadcast to position ALL downrange trackers - there is only one sun, so they will all have to point at the same place :)
OR I will query each one in turn to enquire their last actuator current, current 3-axis position, etc.
Sure, that means each query will likely take 4 seconds, but that isn't a problem as positioning only happens every 10 minutes or so.
 
Re the slower serial comms - at 200ms/bit, 18 bit transmissions, I'm now up to 10 errors in 3500 transmissions. Most of them due to trying to read the PLC status while its in the middle of sending or receiving data. That's better than 99.5% sending rate, which is probably ok.
 
I'd say that isn't too bad. When you get an error does the WC request a resend? In perspective, thats 36 seconds out of 3.5 hours.
If I'm not mistaken, you'll have that whittled down to 99.9% before the weekend is over. :P
 
todster said:
I'd say that isn't too bad. When you get an error does the WC request a resend? In perspective, thats 36 seconds out of 3.5 hours.
If I'm not mistaken, you'll have that whittled down to 99.9% before the weekend is over. :P
 
:)  Yeah, it keeps getting better and better as time goes by without someone poking it :)
 
At this instant, all I've been doing is testing the robustness of the transmissions, and its only one way. One board sending, one board receiving.
I'm waiting on my down-range boards to arrive so I can build them and actually start writing the code for them (they're PICAXE based).
In my particular circumstance, it's unlikely that missing a transmission will be a major problem. An array could be off-line by a degree or two. Big deal. It would catch up next transmission (10 minutes later).
If it's the backchannel comms from the downrange board to the master controller querying say array X/Y/Z angles or actuator current, and there is a parity error (far far more likely since data coming back is much more than going downrange) then the master can just discard the lot and start again. (That's why I wanted to at least code a parity check for some level of confidence)
 
I thought about PV's once, very briefly. The thought of shoveling snow off them every day for 4 months out of the year kind of put a damper on it.
 
todster said:
I thought about PV's once, very briefly. The thought of shoveling snow off them every day for 4 months out of the year kind of put a damper on it.
Erk. As it would.
We get perhaps one (brief) snow flurry here every decade.
I have a 2.5kW wind turbine too, but I like PV. They're quiet, mostly maintenance free and fairly efficient. And a lot cheaper to run than the generator!
 
I now have a board updated to the new .17 . Now to figure out how to use it for the serial. Have you tried the BSL for this Ross?
 
todster said:
I now have a board updated to the new .17 . Now to figure out how to use it for the serial. Have you tried the BSL for this Ross?
 
No, I don't have any boards with that firmware yet. *BOO HOO*.
 
I've got a bunch of boards ready to send back for upgrade, but haven't done so yet. Even then, it'll take weeks to get to CAI, then whatever their turnaround time is, then another couple of weeks to get back to me....  (you can understand why I REALLY want field-upgradable firmware!)
 
I finally got the 7805 compatible switching voltage regulator. Works awesome. Thanks for the link on that Ross. I'm still waiting for my driver I order thats  PNP instead of NPN to drive the 24 VDC sinking inputs. I have the board connected for now with the NPN drivers and zeners/resistors on the inputs. The NPN's required pull ups so the inputs to plc are inverted. The resistors seem to get hot after awhile as well. I will be etching my own daughter board once the parts get here. I think I can also run the 24vdc inputs on 12vdc as well to keep power dissipation lower. 10 vdc appears to be the lowest they'll fire on. I played with some code on both controllers and have the transfer working. I also sent the date and time to keep time on the plc synched. The code on both is a bit kludgy but for this test it works great.
I'm sending 8 temps, 1 humidty, the date and time. 14 16-bit words. Takes about 30 seconds. There is a huge mismatch in the way time is kept on both as well as the way the program runs. I used the W/C to set an output for each bit as a trigger and another at the end of each word. I'm focused on reliability and not speed or only 1 wire between them. There is a Hakko v606 color touch screen HMI htat connects to the SLC 5/04 and displays the info on several different pages as well as display alarms.
http://www.youtube.com/watch?v=aFHbXcglY4Y&feature=youtu.be
 
The tracker board I referenced in another thread a short time ago, is doing similarly, but just using a single pair for bi-directional comms.
 
tracker-bus-comms3.jpg

 
Shown here, the webcontrol turns the bus power on (+12V), sends an 8-bit word (4 bits for command, 4 bits for address), then the downrange device is replying to this command with two, 8-bit words (X and Y angles).
 
So just one pair provides power and communications both ways with a multi-drop configuration.
 
Signals are a bit ratty here because it's an unregulated 24V supply and 100 metres of cable between drive and test node.
 
Back
Top