SteveJanisch

I looked at it. It is mainly an implicit IO driver, but there was (if I remember correctly) also an explicit sample (although I never looked into the details). If you are looking for something to communicate to AB processors, the tuxeip library was very good and I've used it extensively to communicate to SLC and ControlLogix PLCs. The website appears to be defunct, but you can still get it (e.g. from pvbrowser). I'm not sure how it would work through the HMS Anybus module, but it works through "normal" ethernet hardware just fine.

Thanks for the feedback. After having to do this 50 times a day I always think somebody has got to have a better way... but I never find that somebody. There are a lot of things I'd be a lot more forgiving with the IDE if it was v1.0.

Thanks for the posts. It's hard to keep up with the open source community! The IO stack looks very interesting. I'm going to have to look closely at that one. And since tuxeip appears to be abandoned, perhaps the AdvancedHMI stuff will benefit the open source community.

My background is in embedded microcontrollers and real-time programming on X86 PCs (I've only recently been dragged -- kicking in screaming most of the way -- into PLCs). I can tell you that 32-bit boundaries for variables are not something out of the ordinary and that many compilers will default to that... why... because it produces more efficient code. The boundaries are often times linked to the processor, so a 32-bit processor will want to place variables at 32-bit boundaries. I'm not sure exactly what is happening in AB processors (never really had cause to look) but in Siemens you see variables are pushed into byte (or bit) boundaries governed by their size. This too, is fairly normal. So if you have a DB defined with bX : BOOL i32X : DINT You will "waste" 31 bits of memory. The 32 bit DINT will be addressed at offset 32, rather than 0.1 (or even 8 or 16). This produces more efficient code. Although a lot of people may think that packing bits into a word or double word is more efficient, think of what the CPU has to do in order to use that memory. It has to mask that bit out of the word, and then do logic. If all bits were at 32-bit boundaries, this intermediate step wouldn't be necessary. So it could theoretically result in more efficient (and therefore faster running) code. Of course I am not entirely sure which CPUs Siemens and PLCs are using, but I would probably think they are configuring memory in order to be more effieicent with their processors. So just comparing how memory is utitlized is probably not a good indication of the strength of the processor. That's all a bit off-topic, of course. I have used both AB and Siemens PLCs. Both are good overall. As a software engineer I think S7 is a great tool, although the interface is fairly cumbersome... which is pretty pathetic really since this is not something that just came out yesterday. We have a joke in the office... S7 takes you at least seven steps to do anything. BTW... if anyone can make my S7 work a bit easier. I really miss a feature that I've had all my life... in embedded c/c++ as well as AB... which is the full symbol cross reference. If I am in a SLC program and want to look up where else a variable may be used, my only way to search for it is to copy the symbol, open a VAT and print it and get the full address (e.g. DB4:DBD104) then open a ladder program, choose the Go-To function and print the address (see what I mean about the seven steps?). The thing where a VAT can interpret the full symbol, and the Go-To cannot... and the Go-To command can be found in the ladder editor, but not in the SCL led to another joke in the office. S7 is only 70% complete.

The sample code itself only requires "registration"... look further down on the page, there should be an option to "REGISTER to DOWNLOAD EtherNet/IP Example Code." I will state that even with the code, it would have been very very difficult to write an IO driver without the spec. IMHO the sample code is needlessly confusing and is what it is -- sample code (i.e. they are not really trying to teach you the spec by the code). So I generally agree with your frustration. In spite of the non-profit orgranization and open standards, this is really just big business. I'm not really sure exactly what you want... if you merely want the spec you do have to pay ODVA for it, but you don't necessarily need to purchase an ID or become a memeber of ODVA. You only need to purchase the ID if you want to become an ODVA-authorized vendor. Be careful if you order the spec, however, since ODVA will default you to purchasing a specification annum, and will pleasently send you a bill each following year to renew you license. As far as I've had the misfortune, this is pretty much standard operating practive with all such agencies... I've had it happen with CANOpen and ODVA as well. About the easiest spec I've ever come across is EtherCAT. You do have to become a member of the organization, but all you have to do is provide some information about your company (or self if you are free lancing) and you are pretty much in. No annual fees.

Sorry for the very slow response... I only became a member of the forum quite recently. I know for sure that at least v1.0 of tuxeip did not implement the IO porition of EtherNet/IP. The library was mainly conceived to talk to AB PLCs (and it does that quite well). You will be able to use some of the code in tuxeip to build a driver since some of the initial comms to create the IO packet are defined in tuxeip. ODVA itself has example code for an IO server -- http://www.odva.org/default.aspx?tabid=134. I found the code fairly difficult to follow but was able to follow it.