PDA

View Full Version : DL-205 with Co-processor


chip7238
October 7th, 2004, 02:37 PM
Hi all,
I'm new to this site, but have learned a tremendous amount just by looking around.

I am new to PLCs, but am fairly familiar with programming ladder logic. I have a DL-205 PLC with a 260 CPU as well as a co-processor (F2-CP128). I am using a touchscreen on port 1 of the CPU to control a workcell that contains two Adept SmartAxes, among other things. Each SmartAxis is hooked up to the co-processor via RS-232. The reasoning behind the use of the co-processor is so both SmartAxes can be controlled simultaneously (multiple RS-232 ports). Maybe there is a better way...

As of now, I am able to get the co-processor to print ASCII commands to HyperTerminal out of one port (the SmartAxes need simple ASCII terminal-type commands). After looking through much of the documentation of all of the components, I cannot figure out an "easy" way to reliably communicate between the touchscreen and the SmartAxis (i.e. some sort of jog functionality, etc. -- real time would be nice too...).

The co-processor seems to have a low level network communication with the CPU, but nothing as robust as I think I need.

Ideas, thoughts, and questions for clarification are welcome!

Thanks in advance!!

Chip

mordred
October 7th, 2004, 03:08 PM
We will probably need to know what touchscreen you are using as they usually come with different communication standards

Steve Bailey
October 7th, 2004, 03:20 PM
ASCII command strings over an RS-232 serial communications link is not a good combination for 'real-time' control under the best of conditions. Don't the axis controllers have hardwired jog commands? If so connect them to discrete outputs form the PLC. Limit the serial communications link for things like new position targets, velocities, or accelerations.

chip7238
October 7th, 2004, 04:00 PM
mordred: I'm using an Automation Direct EZTouch 6" screen with Koyo serial drivers

Steve: The controllers for the SmartAxis reside on the unit itself and run on Adept's proprietary Micro V+ language. From the conversations that I have had with Adept technical support, I believe your suggestion to use discreet inputs on the controller to begin an action (like jog) will work, but I'm not sure it will work in conjunction with serial communications.

I'll try to explain:

I have a program called Adept Desktop that allows me to program AND control the SmartAxis in real time using the RS-232 port on the axis. By using serial commands exclusively, rather than a Micro V+ program onboard the axis, I am limited to only terminal level commands to the axis. That makes it difficult to utilize built in I/O (since using I/O requires application code onboard to support it).

Here's a link to some Adept control info:

http://www.adept.com/main/products/LinearModules/pdf/Adept_SmartAxis_control_strategies_datasheet.pdf

I figured that using all RS-232 would be the way to go since it seems as if the PC is using this method just fine (through Adept Desktop).

Thanks again!

Chip

Steve Bailey
October 7th, 2004, 04:40 PM
Let's summarize the things that have to happen during a jog.

You press the 'Jog Forward' button on the touch screen. That command is transmitted serially to the PLC. The PLC program includes the command in the packet of information it passes to the coprocessor. The coprocessor extracts the command from the packet and assembles an ASCII string to be sent to the controller. It places the command string in the queue of other pending command strings. When the command reaches the top of the queue, it gets transmitted. When the controller receives the command, it decodes it and executes it. Now assuming that the touchscreen, the PLC, the coprocessor, and the axix controller are all operating asynchronously, there are a lot of places for delays to add up between you pushing the button on the touchscreen and the axis controller acting on it.

It gets worse. Your example is a jog command. I interpret that to mean telling the axis to move at the predefined jog speed until you tell it to stop (or the axis reaches end-of-travel). That means that after the delay between pushing the button and the start of motion, there is a similar delay between taking your finger off the button and stopping the motion.

In my opinion, there are too many devices involved for this to work to your satisfaction.

chip7238
October 8th, 2004, 08:15 AM
Steve:

Thanks for the reply. I think you might be right with the jog command analysis. I wouldn't want that delay to cause a crash -- especially on button release. I will have to try to get the hybrid approach to work - I/O for 'real-time' commands and RS-232 for adjusting velocities, positions, etc.

Thanks again for all your help...I learn something new everyday!

Chip