Odd request RSLogix5000 - Send 80 character string from One PLC to another with I/O

[Rayman_7676]

So I had an odd request from a customer for the above. I have written the logic and tested it all in one PLC with only using 7 outputs and 7 inputs. I did not know if anyone would want to try it out. I have attached what I have with screenshots. Figured it would make a good project for someone. Its not a big deal for me - I really do not want to work with this customer because he wants to do things on the cheap and I am about to tell him to get stuffed. I put the logic through the ringer and I cannot fault out the processor, plus it works. I tried to keep the timers reasonable so not to kill an I/O card - but at max 80 characters it was around 25 seconds to fully update. Tell me what you all think.

 

[drbitboy]

... Tell me what you all think.

Sweet, you've written a parallel port driver!

"It's just zeros and ones, it cannot be hard" - Jouni Rynö

 

[Ken Roach]

This sort of hardware hacking is near and dear to my heart.

I did almost the same thing with a fistful of TTL chips, LEDs, and salvaged fiber optic cables for my 8th grade science project in 1984. An order of magnitude slower than the state of the art, but nobody explained parallel ports and and clock pulses to me.

Once upon a time in rural Ontario, I implemented a bit-shift register between a PLC-5 and a MicroLogix 1000 over a single 120V AC input, to load a preset into a high speed counter.

I think there's probably some risk to the I/O update happening in the middle of a routine... I haven't been able to open and import it yet to see for sure how you did everything.

 

[Rayman_7676]

Drbitboy - I have messed around with serial stuff in the day - but usually to just pass an alarm number. So i figured there had to be a way. I thought about it before I went to bed last night and then had 4 hours of spare time today and knocked it out. I only faulted the processor infinity times. thats what test PLCs are for, lol

Thanks Ken!

Unfortunately I did not those learnings when I was young - It was "go grab a wrench boy" But I was always interested and I got tired of being the dirty guy in the hole looking up at the PLC guy. Old dogs can learn new tricks!

I thought about a shift register but I did not go that way. It probably would be more reliable. Time based logic can bite you in the butt. But this would be a non-critical thing - Updating an alarm string. Most alarm strings are around 30 characters so update time would be around 5 seconds.

I did not have I/O cards to work with or two PLCs. But it is proof of concept. Maybe if I can get back to the office sometime soon Ill try and wire it up. Good call on the I/O update.

 

[parky]

I have done this in the long distant past, a couple of them, however, I used a couple of handshaking bits not timers, for example used 7 bits for the chars & one bit each way for handshake, by using the handshake & transistor outputs it's pretty fast. also did one but the PLC had relay outputs I know it lasted at least 3 years not sure after that as I never went back after that time.

 

[Rayman_7676]

Ahh got yeah - I uderstand what you are saying, but this is only 1 way as requested. So kinda stuck with that. I was trying to figure out what to do with the last bit, ASCII fits nice in 128 so what would i do with the last bit of 8? I mean come on I cant leave one hanging, lol. In the past I would use the decimal value for an alarm for the first 7, But again you are stuck with only 127 alarms - never use 0 as an alarm number.. And then use the last bit as a confirm/done bit. But with ASCII you have any value alarm number you want. What you do with the last bit?

 

[Rayman_7676]

This would be all hard wired and no other connection. chassis are all pretty much loaded, no expansion. No ethernet... Old Compact stuff. L32. I had to beg and plead for what I got. I just said give me 8 out and 8 in, Ill see what I can do. again alarms up to 127. But then my brain went down a rabbit hole, damn controls people. And cheap people pushing more for less, i guess i cannot complain too much, it was kinda fun.

 

[Rayman_7676]

Well if anyone does decide to run it - I have questions. I did lower the receiving side of the logic timer to 265 ms. I was able to get around 16/17 same characters in a row before there was a miss - its additive. The timer on the sending end is 250 ms. 250 devided by 15 is 16.7 Also why is there a nul at the beginning of the string that is being decoded? It is a Decimal value of 0. Plus string lengths love to fault the PLC... Strings.. So may need to work on that logic - but there are stops in place, its just the string is not correct. To all, this is logic running in one PLC in one routine, this is just more of a test than anything. You put 2 PLCs, plus different scan times, Plus wire lenth, and plus debounce of I/O from PLCs. Yeah this may not work. I may just look into the last bit I can send it to index. I would like to keep it at 8 bit only and be reliable, maybe slow but constant. Its just to update an overhead led display connected to the receiving PLC.

Anyway - time to get **** going around here. In Wapakoneta pop 10,000. They project over 100,000 visitors over the weekend and Monday will be nuts. Everyones gotta see the eclipse! Il be in my front yard yelling at them to stay off my lawn. Catch you all next week.

 

[Rayman_7676]

Oh yeah, all of this is existing wired outputs and inputs - just not used. Thats why they are asking - no cost except to program.... Its just 1s and 0s right

drbitboy​

 

[drbitboy]

... Good call on the I/O update.

I think you can use CPS instructions for the final moves to and from I/O, to ensure the I/O scan does not catch you mid-update of the "character" I/O.

I agree you that should use the eighth bit to send a "CLK" to make the transfer and index the counter and get rid of the TON on the receive side, although you might want to let the bits settle after the CLK bit transitions on the send side; maybe use GRT Index_OUT_TON.ACC 200 OTE Local_Out.8 as the clock?

Also, you don't need TON timers on the send side, you could instead increment a dint on every scan cycle on the send side as a poor-man's timer; bit 6 or bit 7 could be the index trigger (bit 7 of the sent "code"), so it sends a character every N (128 or 256) scan cycles, and then it resets every .LEN * N. But that is more like obfuscation.

True ASCII is 7-bit anyway; 8-bit ASCII is ISO-8859-1/8869/LATIN-1.

And from the "six of one, half-dozen of the other," "es ist mir ganz egal" domain (I like to minimize use of vertical real estate; sometimes it even improves clarity ).

​

​

 

[drbitboy]

Move rung 13 to before rung 10 and I think that will lose the leading NULL.

 

[cardosocea]

That was a waste of 10 digital points... You could have bit banged an I2C driver or even SPI one with less.

Now on a more serious note, I remember that the first "remote IO" I worked with was a Siemens Mux/Demux system that worked a bit like a shift register would to activate outputs or read inputs.

 

[Lare]

You have delay 250ms on each character, but another plc is counting character index on evey plc scan?

 

[drbitboy]

You have delay 250ms on each character, but another plc is counting character index on evey plc scan?

"You talking to me?"

or to OP?

I am saying replace the TON with a integer that increments every scan, and every time that integer reaches some power of 2, it resets to 0 (e.g. AND poormansclock FFH poormansclock), and to use the rising edge of the highest bit (bit 7 if AND operand is FFH) as the trigger.

 

[Lare]

"You talking to me?"

or to OP?

I am saying replace the TON with a integer that increments every scan, and every time that integer reaches some power of 2, it resets to 0 (e.g. AND poormansclock FFH poormansclock), and to use the rising edge of the highest bit (bit 7 if AND operand is FFH) as the trigger.

Relax
To OP.
Output coder have ton timer with 250ms delay for adding. Input coder adds every scan if understanded code right.