Opening and Closing the Ports

[Code1131]

Hi this is my first post and I hope I would get information from very Elite people on this forum.

I want to communicate a Master controller to other slave controllers ( here controllers are dedicated PLCs designed for controlling the machines). But the Master and slave controllers work on their own propritory protocols ( all the slaves work on same protocol as they are of same make).
The Hardware iterface is ready with me having two ports and they are sufficient for interfacing.

I have the example software developed for interfacing between ( converting)Propritory protocol and Modbus Protocol. In that software, the blocks used are: Modbus_Open, Modbus_Close etc..
On the similar lines I have to prepare the blocks for Opening and closing the ports for propritory protocols.
If I could know how it is done for Modbus, I would be able to implement it for the propritory protocol.
So whether somebody can tell me what is meant by Opening and closing the port and how it is achieved ( for example in Modbus protool)

Thanking You

 

[Tom Jenkins]

This kind of question that is very platform specific. What is the manufacturer and model of the master and slave units? You will probably have to use RS-485 or ethernet to have a multi-drop system. What is the port on the master and slaves - RS-232, RS485, or etherent?

 

[Code1131]

The hardware interface between the master and slaves has RS 485 port through which I am going to communicate with the devices ( may be master or Slave) who supports multimaster protocol.

 

[Gerry M]

So who is the manufacturer and what are the models of the PLCs you are using?

Also take a look at Modbus.org

 

[Steve Bailey]

There are no Modbus commands for opening or closing a serial port.

In VB, you would execute a line like:

Form1.MSComm1.PortOpen = True

or

Form1.MSComm1.PortOpen = False

 

[(8{)} ( .)]

Hi Code1131

You are going to have to be very specific if you want any meaningful input from the forum.

From what I understand you have some kind of hardware interface. How is it programmed? Is it a PC or a micro-controller based do-hickey?

Furthermore, it seems to me that while the sample code you've got relates to Modbus, neither master nor slave speak Modbus. If this is the case you are going to need the command sets for both master and slave devices.

Another thing, are both the master and slave controllers propriatary? Have you contacted the manufacturers to see what protocol offerings they have? Perhaps the slave unit controllers offer Modbus (for example). While you'd still have to develop and interface to the master this would cut your development time significantly (since you've already got the Modbus sample code).

As for the Modbus_Open and Modbus_Close commands I suspect that they are function calls that open the ports on your gateway (among other things).

Either way, looks like you've got a big job on your hands, try to look for ways to simplify it.

Good Luck,

(8{)} ( .)

(Yosi)

 

[Code1131]

Protocol conversion software

I have a hardware interface (which can be programmed using the languages listed in IEC 61131-3). This has two ports. One is for CAN and one is RS485. This port would act as a port for any fieldbus ( If you load Modbus interface s/w, it will be used for connecting Modbus Devices)
In my case I want to use this port for connecting the compressor controllers( specially designed PLC, not general purpose) having their propritory protocol. I know this protocol and also know the CAN Protocol ( for the controller communicating on CAN port).
Now I have to develop the software which would be downloaded in the Hardware interface so that Controller with CAN protocol would be able to talk to controllers with Propritory protocols.
While doing this I have to do opening and closing of the ports and also transmitting and receiving the messages (I observed it in CAN to Modbus protocol converting software that I have). In case of Modbus, the function block for all these activities were already available.
I want to develope the function blocks for these activities( open, close,receive, transmit) for propritory protocol.
So I would like to have the information on how to develope these blocks, provided that both the protocols are known.

Thanking You,

 

[(8{)} ( .)]

OK.

Since you have sample programs for opening, closing, and communicating with these ports your job should be easier. Before starting to code, however, I would contact the manufacturers of your controllers to see if they offer any standard protocol. Your compressor manufacturer, for example, may offer BACnet and the controllers that talk CAN probably offer a standard CAN protocol as well.

Find out what they offer and repost with the results.

The reason I'm asking you to do this is simple. Growing your own protocol should be a last resort (in most cases). If standard protocols exist then use them. It's a lot less expensive and a lot less frustrating too. (You know how many grey hairs I've got from developing odd-ball protocol interfaces? Don't ask...)

Good Luck,

(8{)} ( .)

(Yosi)

 

[Gerry M]

I definitely agree. Try not to use your own protocol. But I believe you said you are using a proprietary protocol.

You said,
"I want to use this port for connecting the compressor controllers( specially designed PLC, not general purpose) having their propritory protocol. I know this protocol and also know the CAN Protocol"

You also asked:
"So whether somebody can tell me what is meant by Opening and closing the port and how it is achieved ( for example in Modbus protool)
"

So what I, and probably some of the others, are confused with is the "Open" and "Close" functions you are talking about. Like Steve said there is no Modbus open and close.

In normal programming(VB,C++,etc.) you would open and close the hardware port. But all that does is allow your program to use the hardware resource. This code is s/w-h/w dependent and usually has nothing to do with the protocol. That is why we keep asking you what exact equipment you have. It is very difficult, in this case, to help you without this information.

What are you working on, a military job?

 

[Code1131]

Transmit Receive operations

Gerry M,
The situation is : Adding a compressor of make 'A' to the existing network of compressors of make 'B'.
Controllers of Compressor of Make 'A' has their propritory protocol(multimaster RS 485 based), and the controller of compressor 'B' is having CAN protocol.
The situation may also reverse.
I wanted to write the software so that both controllers can communicate with each other through a hardware interface which is already available (having one CAN port and one RS 485 port)
So I will have to write the functions for transmit and receive operations.
Does Transmit means putting the data in a specified location of the controller and receive means reading the data from the other specified location? Or it is done by some other way?
As I said earlier I know both the protocols, but I am totally blank about how the Hardwaere interface will do the Transmit and Receive opreations?

I hope now my problem has got well explained to most of you on the Forum

Thanks in advance and also thanks to all of you for showing interest in my topic and coming forward with helping hands.

 

[(8{)} ( .)]

Hello Code1131,

I'm going to be blunt. If you don't know what transmit is you're probably in over your head.

Since nobody here knows the make or model of your gateway nobody here will be able to give you any particulars.

The best I advice I can offer you is get in touch with the gateway manufacturer and ask for advice.

Good Luck,

(8{)} ( .)

(Yosi)

 

[Gerry M]

It was blunt, but to the point!

Yosi one of these to ya'! beerchug

 

[Tom Jenkins]

First off, controllers are like teenagers. They all think they are the center of the universe. Transmit and receive are always in reference to the controller itself.

You aren't going to get good answers without knowing exact manufacturer and model number of all of the equipment in your system. That includes your communications bridge.

I'm inclined to agree with Yosi - you have at best a very steep learning curve to get up.