Chris Morley wrote: > > Date: Sun, 7 Dec 2008 18:18:18 -0500 > > From: [EMAIL PROTECTED] > > To: emc-developers@lists.sourceforge.net > > Subject: Re: [Emc-developers] Classicladder 7.124 opinions > > > > 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 totally agree. What makes MODBUS so flexible also makes it hard to > program > an easy interface for. > > > 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. > > > > That would be fine for advanced users but it's a killer for newbies and > Windows people used to point and click. Just follow CNCZONE , try and > help out on some problems and see how difficult it is for new people to > be successful. They never read the manual because the rest of the world > is point and click.
While I do like things to be easier rather than harder, I don't have much sympathy for someone who can't write words in a text file or read a manual. GUIs are complex because they have to expose the underlying complexity of the system, but they're (usually) discoverable - a newr user can see options that they don't know exist because they're sitting there on screen. CLI or text files are complex because you have to know what you're doing to make it work. The GUIs have an advantage in that they usually have a much shorter modify / test cycle time. > > > 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. > > The GUI is quite basic I'm sure it needs help. But the best thing is you > can watch the vars window to see if the info is being sent/received > And you don't have to connect HAL pins to do it. I don't know about you > guys to I HATE connecting 20 pins just to test something. I use HAL > alone more then with EMC so ya have to type in a million lines all the > same > except for a pin number. > Pyvcp is great but again I hate having to type a million lines just to > visually test something. I am spoiled with CL :) Heh. I've been mulling over how to write a program that lets you create a pyvcp panel with controls/indicators for some hal pin spec: makevcp parport.0.*in would give you a file that has a column of input pins and output pins that match that name search. Haven't done it yet though :) > > > > > 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'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. > > > > Ya don't beat me up too bad when you look at the code :) > It's a blend of Marc's and I, and I have only been programming > part time a couple of years - CL is my first programming in C. > I find GUI programming difficult... Indeed. > Yes the Modbus is a userspace program that is why the GUI > must be running for MODBUS to work. Actually there is a > RT serial driver available for RTAI but it is old - and wouldn't > compile - I don't have the knowledge or the time to spend > to get it to compile. > > Are the routines your own or are they from somewhere else? > there is a modbus library avaiable though the author was not > very helpful... I used one of the two modbus libraries I know of, and the author was responsive when I asked about the license (he changed to LGPL3 in the later version of the library, which is why I stuck with the older one). This one is from <https://launchpad.net/libmodbus>. I made a couple of changes to his library (which I should email back to him), to prevent the library from printing error messages - a no-no for library code IMO. - 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
