adccommunitymod (AutomationDirect) asked a question.
Created Date: March 26,2010
Created By: jgreen
**** This post has been imported from our legacy forum. Information in this post may be outdated and links contained in the post may no longer work.****
I'm communicating with an air-handler/temp-humidity controller with a DL06 PLC through port 2. I'm sending ASCII character commands through a three wire rs232 cable(RX,TX,COMMON) connection. The RTS and CTS pins are connected together at the PLC. I'm using the VPRINT and PRINTV commands to write data to a memory address and then send the data out port 2. For example, to turn the air-handler run condition on/off, I first write the command "=OO " "$0D " to a memory address using VPRINT and then send(print) it out port 2 using PRINTV. I'm able to send the machine commands successfully, even commands to change things such as temperature set-points using commands like "=SP " "$20 " 1234 "$0D ". The problem I'm having is receiving data in through port 2. For example, if I want to get the current temperature value from the air-handler I must first send it a query command and then the machine sends back a response containing the requested data. To do this I'm using VPRINT and PRINTV to create and send out the query command. I'm then using the PRINTV complete bit to activate the AIN command to receive the data as soon as the send is complete. The problem is that the AIN command does come on but stays busy as if it never received data and is still waiting. I'm thinking that the change from send to receive is not fast enough and that by the time I 've switched to receive, the data has already been sent. Now, I have been able to communicate with both the PLC and air-handler through the Hyperterminal program in Windows. When I send the air-handler a query command through the Hyperterminal, the air-handler sends back a response instantly (space,4-digit number,CR). When the PLC's AIN command is busy "waiting " for data, I can send it the same data I received from the air-handler (space,4-digit number,CR) and the AIN command completes and receives the data. To sum it up, the PLC is definitely sending the right data to the air-handler. The air-handler is definitely sending the right data back to the PLC. I proved this using the Hyper-terminal. It just seems that the PLC is not ready to receive the data soon enough. Does this seem possible? Are there any settings I could have missed for port 2 that could affect how fast the PLC can be ready to receive after sending? Could any of these problems be solved with a different model PLC? I would definitely appreciate any help I could get with this. Thanks
Created Date: March 26,2010
Created by: bcarlton
the air-handler sends back a response instantly
The DL06 ports is not intended for high speed turn around communication (send then receive) as you are finding out. You may need to use a BASIC module if you have a free slot.
If you are able to adjust communication parameters in the air handler to impose a delay before responding you may be able to solve your problem that way.
Created Date: March 29,2010
Created by: stimpsonjcat
Even if you did make it work, it would be a time-bomb waiting to fail at some later date if anyone ever added more code to the unit.
I agree with BC, get the copro if you need conversational ASCII.
Created Date: March 30,2010
Created by: FACTSTech
See example program f0comex8.abm at www.facts-eng.com / select 'BASIC Examples ' / select 'serial Communication Examples ' / scroll down.
This example could be used as a framework for this F0-CP128 application.
Created Date: September 29,2010
Created by: david_h_b
7 bit or 8 bit ?
I have used the DL06 port many times. They have all been 8 bit up to 9600 baud. I am having a problem right now with 7 bit even parity @ 4800 baud. I changed it to 8 bit with no parity to see where the parity bit is located and it is the MSB ??? I can not change the device to 8 bit. I get string OK with hyperterminal.:confused:
Created Date: September 30,2010
Created by: bcarlton
I had to refresh myself on bit order in serial transmission. It is least-significant-bit first so yes the parity bit would show up as the most significant bit if you choose 8 bit no parity. If you are only receiving then it shouldn't be too much problem.
The problem is, if you transmit you will have to calculate the parity and set or reset the MSB of each transmitted character appropriately or it will be rejected at the other end.
Created Date: March 30,2011
Created by: trevorstripling
Could this be done with a D0-DCM module?
Created Date: March 30,2011
Created by: bcarlton
It doesn't have a setting for 7 data bits which is what david_h_b needs.
He may need to use the F0-CP128 BASIC module
Created Date: March 30,2011
Created by: trevorstripling
Is that due to his 7 bit response? "space,4-digit number,CR " How does it affect the request string?
And if so, would it work with 8 data bit response?
Trevor
Created Date: March 30,2011
Created by: bcarlton
If something is sending with 7 data bits and an EVEN or ODD parity and the receiving unit is set to 8 data bits with NO parity then received messages will be ok if the top bit is masked out because it will be on half the time and off half the time.
Going the other way the message would have to be examined character by character, the parity of the lower 7 bits determined and the 8th bit set or reset according to the algorithm. Then the string could be sent.
In other words a CPU trying to do this through its serial port would barely have time for anything else. The BASIC module is already set up for flexible high speed communication. Use the right tool.
Created Date: April 05,2011
Created by: trevorstripling
Ok. Basic module it is. Thanks.
Trevor