Serial data from 1 output to1 PLC input

[todster]

I'm thinking of hooking an output of my W/C to my Allen Bradley SLC500. It does not have network capabilities (too costly) :angry2:
I would like to xmit the temps and analog data to the SLC500 from the W/C. Also use the W/C as a backup if the SLC fails or a component fails.
The SLC500 has an interactive touch screen that I've added to it and program it for whatever I want to display. I can use this screen to do my alarms, display data and enter data that can be moved from the PLC to the W/C if needed.
Problems:
1: The SLC has 24VDC inputs(at least the modules I have)
I plan on using an ULN2003A to convert the TTL to 24vdc.  2 are on the way from ebay.
 
2. Figuring out the code to use to xmit the temp sensor data as a string with seperator for the pulses and another seperator for end of string or begin string.
Would it be more more useful to set the outputs up as BCD and use several? The ULN will give me 7 outputs total.
 
I'm thinking if I can create some code that will xmit and receive serial data on an input and output, I free up my I/O.
Anyone ever try something like this or have any suggestions on the code?
Thanks

 

[CAI_Support]

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.

 

[todster]

I'm not looking for a serial port. I want a timed pulse stream from an output on the W/C with a start bit or way of indicating start and end and possibly a check digit. The input on the  PLC will decode the timed pulses and reconstruct the number.

 

[rossw]

I'm building exactly such a system now!
Bi-directional communications with low-data-rate bit-bashing over a single pair (including power to run a motor)

 

[CAI_Support]

I'm not looking for a serial port. I want a timed pulse stream from an output on the W/C with a start bit or way of indicating start and end and possibly a check digit. The input on the  PLC will decode the timed pulses and reconstruct the number.

If you do that, you will need to make sure your pulse length are in unit of 100ms, that is the time WebControl guarantee to read input even it is busy with something else. In most time, WebControl will get the input immediately, however, it it is in the middle of sending emails, or doing any other things, WebControl will break away from whatever it doing to check I/O status.
 
More reliable way is to have both sides to confirm the communication through another input line. say IP1 is your input for command, IP2 will be your ready bit. Once you read the ready bit, you will let other side know by set an acknolege OPx and waiting the IP2 to go off.  You will take two pairs of I/O for that. but that is doable.
 
If both sides are WebControl, then you can use the new WEBSET feature to set VAR on both sides as a way to communicate to each other.

 

[rossw]

I've got the concept sorted out in my head but waiting on my PCBs to arrive before I start coding. My plan is to bit-bash a low speed (1-2 bits per second) signal out. Each device downstream will have its own address, I can send commands to one device, or a broadcast address for all devices.
Like I say, haven't built it yet, but not anticipating any major problems. (Obviously, this is doing a lot more than "merely" communicating status)
 

 

[rossw]

I've just hacked a quick "proof-of-concept" code together, and made a little video that I'll try to upload shortly.
 
One-wire. Arbitary number of bits can be sent. Currently being sent at 200 milliseconds per bit, but thats easily adjustable.
I'm
going to change the order of bits being sent, and add some robustness
to the start of the transmission - including perhaps making the receiver
work out the speed from the start bit itself. Not sure if the WC has
the granularity to do this yet or not.
 
Here is the code for the transmitter
 

START    
        SET VAR8 200  
RESTART:
        DIV CTS 86400 RAM1
        MUL RAM1 86400 RAM1
        SUB CTS RAM1 RAM1
        SET RAM2 16  
        CALLSUB SEND   
WAIT:
        DIV CS 6 RAM2
        MUL RAM2 6 RAM2
        TSTNE CS RAM2  
        GOTO WAIT   
        GOTO RESTART   
        END    

SEND:
        SET VAR1 RAM1  
        SET OP8 1  
        SET OP1 1  
        DIV VAR8 2 RAM3
        DELAY RAM3   
        SET OP1 0  
        DELAY RAM3   
        SET OP8 0  
SENDLP:
        ANDB RAM1 32768 RAM3
        AND RAM3 1 OP1
        DELAY VAR8   
        MUL RAM1 2 RAM1
        DEC RAM2   
        BNZ  SENDLP  
        SET OP1 0  
        RET    
 
And the receiver:
 

START    
        SET VAR8 200  
RESTART:
        CALLSUB READ   
        SET VAR1 RAM1  
        DIV VAR1 3600 VAR3
        MUL VAR3 3600 RAM1
        SUB VAR1 RAM1 RAM1
        DIV RAM1 60 VAR4
        MUL VAR4 60 RAM3
        SUB RAM1 RAM3 VAR5
        MUL VAR8 2 RAM1
        DELAY RAM1   
        GOTO RESTART   
        END    

READ:
        SET OP8 1  
        TSTNE IP1 1  
        GOTO READ   
R1:
        TSTNE IP1 0  
        GOTO R1   
        SET OP8 0  
        SET RAM2 16  
        SET RAM1 0  
RDLP:
        MUL RAM1 2 RAM1
        DELAY VAR8   
        ADD RAM1 IP1 RAM1
        DEC RAM2   
        BNZ  RDLP  
        RET    
 
And the video is here:
http://general.rossw.net/webcontrol/webcontrol-serial.m4v

 

[todster]

Looks good Ross. Haven't tried it yet. Not off work until monday. I've been trying to get my boards to pass authentication through Forefront TMG so I can play with them while I'm at work but so far they don't seem to like it. They only seem to work if I access them directly through the port on router before TMG. I can only send http to one port this way.
How is the receiver detecting the start of transmission? I plan on xmitting temps to my PLC. I'm trying to grasp the concept of:
 

DIV CTS 86400
RAM1        MUL RAM1 86400
RAM1        SUB CTS RAM1
RAM1
 
I'm not clear on how this would place anything other than a 0 in Ram1. It obviously works as your video shows. I haven't spent muich time on this yet but your code is something I probably woudn't have thought of. But then again I'm not a programmer either.

 

[todster]

Hi Ross. I still can't grasp how you were using the 32768 to iterate thru the bit positions.
Here's something along what I was thinking.
I haven't tried it yet.
 

Set Ram4 1
SENDLP:
AndB ram1 Ram4 OP1
"AND RAM3 1 OP1" Not needed?
Delay Var8
Mul ram4 2 ram4
........

I'm not even sure I need the ram3, just need a way to directly place the zero bit status on the OP1
My PLC has 1 shots, latches, etc so with these I can set timers and I could actually send a certain length bit and silence to use as my start sequence.
 
If IP1 = 1 ONS Latch
If latch = 1  start timer(1)
If IP1 = 0 unlatch and start timer(2)
If timer(1) accumulator< = 10ms set word1 bit 1
If timer(2) accumulator <= 10ms set word1 bit 2
If word1 bit1 and bit 2 =1 move word1 to word2
start receiving 



 

 

[rossw]

How is the receiver detecting the start of transmission? I plan on xmitting temps to my PLC. I'm trying to grasp the concept of:

 
I send a start-bit which is a half-time-length '1', followed by a half-time-length '0'. The 1->0 transition provides the sync point.
 

DIV CTS 86400
RAM1        MUL RAM1 86400
RAM1        SUB CTS RAM1
RAM1
 
I'm not clear on how this would place anything other than a 0 in Ram1. It obviously works as your video shows.

 
Integer maths.   cts is the current total seconds.
Divide by 86400, and you get the number of days since the epoc. Multiply the days since the epoc by 86400 and subtract from cts and you end up with just the number of seconds so far today.

 

[rossw]

Hi Ross. I still can't grasp how you were using the 32768 to iterate thru the bit positions.

 
It's just the 2^16 bit. It needs changing depending on how many bits you're sending. Thats the main reason I'm thinking of sending LSB first, it'll simplify the code somewhat.
 
 
 

 

"AND RAM3 1 OP1" Not needed?
Delay Var8
Mul ram4 2 ram4
........
I'm not even sure I need the ram3, just need a way to directly place the zero bit status on the OP1

 
There's an anomoly with the webcontrol using andb to directly set an output. It doesn't! I'm going to report a bug, but wanted to finish identifying exactly what is going on. On the status page, it shows the output not as '0' or '1' but as a dot, or a little diamond, or other odd characters - but doesn't set the output.
Hence storing the output into a ram and then doing the logical (rather than binary) and to force the output to the bit state. Using a bnz would require two test conditions - one for bit high, one for bit low. Messy.

Here's a really rough flowchart that may help you get your logic straight in your head

 

[rossw]

I'm about to leave for Melbourne for the day, so just a quick one.
 
I've re-coded to send LSB first. It makes the receiver more convoluted. I'd LOVE shift commands!
SHL a b c    Shift left (a) by (b) bits and put answer in (c)
SHR a b c   Shift right (as above).
 
Anyhow, here's the altered code. (Also changed to send 17 bits, as seconds-in-a-day needs at least 17 bits!)
 
Transmitter:

START    
    SET VAR8 200  
RESTART:
    DIV CTS 86400 RAM1
    MUL RAM1 86400 RAM1
    SUB CTS RAM1 RAM1
    SET RAM2 17
    CALLSUB SEND   
WAIT:
    DIV CS 6 RAM2
    MUL RAM2 6 RAM2
    TSTNE CS RAM2  
    GOTO WAIT   
    GOTO RESTART   
    END    

SEND:
    DELAY 500   
    SET VAR1 RAM1  
    SET OP1 1  
    DIV VAR8 2 RAM3
    DELAY RAM3   
    SET OP1 0  
    DELAY RAM3   
SENDLP:
    ANDB RAM1 1 op1
    DELAY VAR8   
    div RAM1 2 RAM1
    DEC RAM2   
    BNZ  SENDLP  
    SET OP1 0  
    RET    
 
 
And receiver

START    
    SET VAR8 200  
RESTART:
    CALLSUB READ   
    SET VAR1 RAM1  
    DIV VAR1 3600 VAR3
    MUL VAR3 3600 RAM1
    SUB VAR1 RAM1 RAM1
    DIV RAM1 60 VAR4
    MUL VAR4 60 RAM3
    SUB RAM1 RAM3 VAR5
    MUL VAR8 2 RAM1
    DELAY RAM1   
    GOTO RESTART   
    END    

READ:
    SET OP8 1  
    TSTNE IP1 1  
    GOTO READ   
R1:
    TSTNE IP1 0  
    GOTO R1   
    SET OP8 0  
    SET RAM2 17
    SET RAM1 0  
    set ram3 1
RDLP:
    DELAY VAR8   
    MUL RAM3 ip1 RAM4
    ADD RAM1 ram4 RAM1
    mul ram3 2 ram3
    DEC RAM2   
    BNZ  RDLP  
    RET   

 

[todster]

 I got it. I was trying to understand how you were doing a BSR and was too nearsighted to see the BSL. You're taking it by MSB and doing a BSL I'd noticed that the bitwise did not set the OP like a normal operation would. I think I recall something about CAI saying it couldn't be used for that but I am getting older so I might have had a senility slip.
I still can't get the EPOC. I understand a day is 86400. if I follow the logic or think I follow the logic:
CTS= 123456789
Day = 86400
DIV 123456789  86400 Ram1(1428.898)
MUL Ram1(1428.898) 86400 Ram1(123456789)
Subtract Ram1(123456789) CTS(123456789) Ram1(0)
 
Either your W/C runs really slow or my math sucks. If I had to choose I'd pick my lousy math..

 

[rossw]

 I got it. I was trying to understand how you were doing a BSR and was too nearsighted to see the BSL. You're taking it by MSB and doing a BSL I'd noticed that the bitwise did not set the OP like a normal operation would. I think I recall something about CAI saying it couldn't be used for that but I am getting older so I might have had a senility slip.
I still can't get the EPOC. I understand a day is 86400. if I follow the logic or think I follow the logic:
CTS= 123456789
Day = 86400
DIV 123456789  86400 Ram1(1428.898)
MUL Ram1(1428.898) 86400 Ram1(123456789)
Subtract Ram1(123456789) CTS(123456789) Ram1(0)
 
Either your W/C runs really slow or my math sucks.

 
Your math sucks
 
DIV 123456789  86400 Ram1(1428 INTEGER)
MUL Ram1(1428) 86400 Ram1(123379200)
Subtract CTS(123456789) Ram1 (123379200) Ram1(77589)

 

[todster]

It aint the math that sucks, I think it's the old age creaping up.