Hi, I don't know a lot about how EMC works, but I do know quite a lot about Modbus.
Modbus data basically consists of 2 data types, bits (discretes an coils) and 16 bit words (input, and holding registers)> There are also special representations of multiple registers (flloating point etc). The interface is designed so that data is transferred at periodic rates and can be looked at as a shared memory interface. The modbus interface transferes the data between the master and slaves at a rate required by the applications using the data. THerefore one option for an interface scheme is to setup the Modbus master with a schedule of transactions to perform such as; Slave_id, operation, number of items, rate The slave_id is the subaddress of the slave. The operation is the modbus command such as read_holding register, write coils, etc, The number of items is how many registers, discretes are to be read or written. The rate is the periodic rate that the operation is performed, 25Hz, 50Hz etc. For each one of the transactions that have been set up, there will been to be a data array for holding the data that is read or written. It is this array that EMC interacts with. With the above you have a schedule of events to be performed. This is independent of how EMC is going to manipulate the data. As EMC interacts with the data array, the data is transferred to/from the slave independently. If nothing else, it may be food for further thought. Cheers, Peter. Kirk Wallace wrote: > On Mon, 2008-01-28 at 05:02 +0000, Chris Morley wrote: >> I would think a loadable config file would be nessasary as every >> device is different as far as how many, what type ,and what address of >> the device/data. That seems to be why MUDBUS was used so much - they >> didn't force much format to the data packets. > > Every time I read the Modbus specification I realize something new or > that I misunderstood. I thought that I could treat Modbus coils and > registers like parport pins, the function of the pin is determined by > what you hook to it. > >> If you had a loadable config file your module could load that file >> then make HAL pins to suit. Then you would only need one MODBUS module >> -it would just load different/more configs for different devices. >> Classicladder uses this type of idea. It has a config window that you >> set all this info and assign varriables to MODBUS addresses. You can >> set it to access data in multiple discontigous ranges. It is loaded >> when you load the ladder program. > > I like this idea, but I am getting used to creating a custom module for > each piece of hardware. I am leaning towards having a macro that could > be used to automate the process like Stepconfig. I am having difficulty > figuring out what Classic Ladder is because it seems it does a number of > functions that I am used to thinking of as being separate. Is it an > editor, software PLC, or user interface? > >> I am wondering what people are using to connect to their VDFs -MODBUS >> wise. I have a VDF that uses rs-485 or rs-422 but of course I only >> have a serial port. I have seen converters from serial port (rs-232) >> to rs-485. I've heard of USB to rs485. I did see that MESA makes a >> daughter board that plugs into the 5120 (which I use) that will >> produce rs-485. The problem with that is a driver needs to be written >> and worse, I lose alot of input/output > > I tend to not worry about I/O because I can always throw up to eight > parallel ports into the PC. If I need more than eight, it's a small > change in the EMC software. > > For the RS-485, I am planning on using an RS-485 transceiver on a serial > port, and using Classic Ladder's serial_linux.c software as a model. I'm > planning for an HAL component for the device which packages the data and > a Modbus RTU component which sends any messages in a buffer through the > appropriate serial port. Apparently CL talks to the serial port as if it > is a file, which I believe all hardware in Linux is. I am not familiar > with doing this in C, but it seems to be a common practice. My book on C > has a chapter on low level file operations, so I have a reference and > examples to work from. RTS will toggle send/receive on the transceiver, > which is a mystery to me, so I guess I'll need to study how UARTS work > in Linux (again). I think both components can be in user space, and the > Modbus part may not even need to be an HAL component. > >> I'm going to go try to figure out how to make a branch of 2.2.3 for my >> adaption of Classicladder V7.124 with MODBUS enabled. >> Then I hope some of you can try it and see what needs to be done to >> make it work as right now I have no way to test it. > > I am concerned that we may have some common ground with our projects. If > I had a better understanding of what needed to be done, I may be able to > help. > >> Chris Morley > > -- > Kirk Wallace (California, USA > http://www.wallacecompany.com/machine_shop/ > Hardinge HNC lathe, > Bridgeport mill conversion, doing XY now, > Zubal lathe conversion pending) > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > ------------------------------------------------- http://www.homanndesigns.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
