Chris Morley wrote: > > > > > Question about MODBUS: I haven't looked at the CL modbus code, but > > would it make sense to put the modbus stuff into a separate driver (at > > least for master mode, where CL is getting info from slaves), and > > connect it via HAL? > > Yes and no :) > > having a PLC that communicates via MODBUS is not a stretch by any means. > I would think that most people that want to get info from a MODBUS slave > would also want to condition the info in ladder- that makes this way, > more direct. > CL has a nice (familar?) GUI to set up and monitor MODBUS. > I would also think that any one who is going to use a slave device > probably > already uses CL.
Maybe, maybe not. There are devices like the Homann Designs ModIO card, which have encoder inputs (that could be useful connected directly to halui). Also, buttons on a simple I/O card like that wouldn't really need CL, they may be more directly usable with halui. There were some discussions at Fest about how to make a modbus system that's flexible enough to be useful for a wide range of devices, and it's not too easy to do. I'm imagining something a little like pyvcp, where there's a file that describes the interfaces, unit ID numbers, and register/coil addresses, and lets you assign HAL names to them. > The biggest reason of all was because the code was already there-it > was deleted > in EMC's CL version 7.100- I have tried to add more features and make > it more > flexible to use. Sure, keeping whatever is there makes sense - fewer changes means a patchset is easier to maintain. > If you don't want ladder then yes a separate component would be great. > But that means for the used-to-windows crowd you need to make a GUI > and could possible have hundreds of HAL pins. Well, what is the GUI like for MODBUS related setup in CL? I know there's a graphical ladder editor, but I haven't looked at the CL/MODBUS UI at all. > I see CL as a general way to communicate to MODBUS slaves. > The other MODBUS component just check in by Seb (right?) > is a more specific, thought now it is easier to make different > components. Yes, the GS2 driver is a reasonably good starting point for other device-specific drivers. The library is LGPL2 (in this version anyway), and it's pretty easy to use. > I guess I could pull the routines out and cobble together a stand > alone program but I think I would rather let people try CL > find out what works what doesn't then either improve CL > or make a completely new program using different MODBUS > routines. I'll take a look at how the MODBUS stuff fits into CL - it's got to be a separate userspace component since RT code can't access Linux devices (unless there's a serial port driver that goes direct to the chip). It may be that the CL MODBUS driver is where to start, maybe just by adding the option to export some values to HAL with user-specified names. - Steve ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
