Hi all

My PLC hardware project has lain dormant for the winter so I could pursue my true passion, avoiding hypothermia. But, with the advent of above zero weather and the continued desolate job market, I am scrambling to bring it out of hibernation. The Beagleboard contest went nowhere with no explanation, so I see little chance of obtaining a Beagleboard for development on a shoestring. But there's a new contest for a smokin' hot boardual-core ARM(R) Cortex(TM)-A9 MPCore(TM) with Symmetric Multiprocessing (SMP) at 1 GHz each. (I cut and pasted that:^) It's called the PandaBoard http://www.pandaboard.org.

I want to concentrate on the hardware and platform in general, so I'm looking to partner with an OSS automation software project. Objective: a powerful PLC that has the horsepower to be self hosted, drive DCS, run realtime machine vision tasks, CNC, sophisticated HMI, etc. This thing has serious horsepower, ethernet, etc, etc. I'll bet it's not low power, but the resources should be enough to run PC class software. For $174.00

My question is will MBLogic, PCBrowser, or some other software fit on this thing so as to have a working product as the seed for the stone soup? Is anyone willing to try? I can write up a project with the existing PLC hardware design and the Panda if I have something to run on it.

Regards
cww

 

One of the features in HMIServer was written for a user who wanted to run it on ARM boards in building control applications. According to him it worked fine. I don't recall what the actual hardware was though, and he is in Europe so I never saw the actual hardware. So, you're not the first person who has wanted to do this.

For MBLogic you need the following:

The MBLogic soft logic system: 20 MB. On top of that you need the Twisted libraries which are another 14 MB. For MBLogic itself, about 75% of that size is documentation. About 5 MB of that size will disappear in the next release because a lot of the HMI related documentation will get moved into HMIBuilder (a new program which builds the HMI web page for you based on menu selections). So, call it about 30 to 35 MB. I'm not counting Python in this total, because that is part of the standard OS install for most modern distros (a lot of the OS management software depends on it).

HMIServer (stand alone web based HMI): about 10 MB. It does not require Twisted, and like MBLogic Soft Logic about 5 MB of that will be disappearing in the next release (with some of the documentation being moved into HMIBuilder).

The Pandaboard site lists Ubuntu as one of their recommended distros. I just checked the Ubuntu repositories, and Twisted is in the ARM repository. Debian would be another distro to consider even though it isn't listed on the Panda site (Ubuntu is based on Debian).

I think this would be an interesting project, and I would be happy to help you to get it to run on your board.

After a recent rather interesting discussion with James Ingraham I have been giving some serious thought to a "next generation" version of MBLogic based on the Redis in-memory database. I checked Ubuntu and redis-server is in the ARM repository as well (and it's less than 500 kB in size). I am mentioning this because a "next generation" design would be based on taking the existing program and breaking it up to make it both more modular and expandable. I am mentioning it here because that opens up a number of new rather interesting new application possibilities for it and makes adding new features (or application customization) a lot easier. I have to do some serious benchmark testing to see if this is feasible however, but I will do that after I get HMIBuilder released. I am guessing the size for this would be roughly the same as the existing version of MBLogic.

 

That sounds good enough for me to propose it for the contest. The rebirth is conditional upon my winning a board of course, and if I win a board, I'll try to submit the PLC boards to be fabbed. I'm free of the constraints of unemployment insurance, that having run out. If I find a job before my retirement runs out, I'll spring for the boards en masse. Otherwise I'll have to maybe do one at a time. It looks like the Panda wants some stuff I don't have, like a HDMI monitor and USB KB and mouse. But those should be scroungable. I'd cut you in on half my development budget, but the postage would eat it up:^). What consulting I've been able to drum up has been invested in red oak for the stove, but the weather is supposed to moderate eventually and I shouldn't need more than I've got so, some billable time could speed things up.

Regards
cww

 

OK, So I proposed it on the pandaboard site, Black Market Archive.
Michael, could you go to the wiki and add your preferred contact info
and as much as you want to say about your software? I really think that would help, and I admit I am not familiar. Heading is, what else?, PandaPLC.

Regards
cww

 

I have added the requested information to the wiki. For public contact I have used the forum address for my project site, as I don't want my e-mail address getting spammed to death.

I put a short blurb in to explain what MBLogic is, so that it will show that you intend to use existing and established software as I suspect that will show your project is more likely to come to fruition than a purely blue sky effort. You can go ahead and edit that bit if you don't like it however.

You can contact me directly though through the developer contacts e-mail address you will find if you download MBLogic and look in the "MBLogicInstall.pdf" file for the "general contacts" address (that one will be mine). That's an address that I set up specifically to support the project.

Unfortunately I get enough spam from people trying to sell me Chinese control valves or web development services that I have to be careful where I post my address in public.

 

Thank you Michael

I hope it is judged worthy, and if nothing else you get a little ad space. The PandaBoard would be mild overkill, but you can't always find a contest for the best match and faster is almost never a bad thing.

Regards
cww

 

> My question is will MBLogic, PCBrowser,
> or some other software fit on this thing
> so as to have a working product as the
> seed for the stone soup?

pvbrowser is a client/server framework.
In this case i think only the server needs to run at the board.

If the board runs Linux you can probably run the server without any modifications. The server only needs the standard C library, sockets and pthread routines. Qt is only used in the client. Qt is not necessary for the server.

I would suggest that you evaluate a "hello world" pvserver on your board and contact us on
http://tech.groups.yahoo.com/group/pvbrowser/
for further discussion

 

> My question is will MBLogic, PCBrowser,
> or some other software fit on this thing
> so as to have a working product as the
> seed for the stone soup? Is anyone
> willing to try? I can write up a project
> with the existing PLC hardware design
> and the Panda if I have something to run on it.

About pvserver:
I think a good idea would be to use Lua for the pvserver because then the user does not need to worry about processor architecture.

In order to get an impression about the needed size here is what is needed:<pre>
-rwxr-xr-x 1 pvbrowser users 1325144 20. Mär 16:59 pvslua
-rwxr-xr-x 1 root root 301084 20. Mär 17:25 /opt/pvb/pvserver/libpvsmt.so
-rwxr-xr-x 1 root root 937064 20. Mär 17:25 /opt/pvb/rllib/lib/librllib.so
-----------------------------------------------------------------------</pre>
That is: 2.6 MB of code for your pvserver !!!
+ the Lua script

Thus i do not see a problem to run it on a system with limited resources.

Here you can see an example pvserver in Lua:
http://pvbrowser.de/pvbrowser/index.php?menu=3&topic=3

PS:
pvbrowser is already running on ARM processor (Nokia N900 with Maemo).

 

I checked and I don't see your changes. Did they get saved? (I apologize for the late notice, I've had domestic issues.)

Regards
cww

 

The changes were there. I suspect that they got reverted due to their spam filtering system, since I'm not the registered "owner" of the project.

After I did the edit I got an e-mail asking me to confirm the edits. Did you get a confirmation request? If you did and you didn't confirm it, they may have automatically backed out the edits. I imagine that they would have some sort of system in place to limit the changes that third parties can make.

 

Well, it may not matter, I didn't see anything and apparently the judges aren't too interested in PLCs. The winner was a football playing robot. I'm not entirely sure how to interpret that, but I'll try again. It would make for a really innovative PLC. Just bring your notebook, open the cabinet doors and you're connected. It may even have the power to be self hosted.

Regards
cww

 

Well, I didn't win a high powered ARM processor board for the PLC project, and the cash to buy one would be better spent just getting a set of boards made and populated. To that end, I ordered another Freeduino Serial V 2.0 to dedicate to testing the hardware. There is a SPI library and enough digital I/O for the chip selects and the ATMega328P is a reasonably powerful RISC processor with 32k of flash 2k of RAM and 1k of true EEPROM. It's an 8 bit processor but can achieve 1 MIPS/MHz with good code. It provides a good vehicle for testing the SPI bus idea and the hardware for $22 shipped as a kit. It can be programmed with the popular, free, Arduino sketch tools and there are, of course, gcc and libraries along with AVRDude to program it in C. I mention this in case anyone but me would care to do so. I don't anticipate being able to write high level tools for an 8 bit uP, but having a working SPI driven hardware set would allow people to install almost anything as a processor that can do SPI. It may well be just a testing boondoggle, but at least progress can be made. If I can scan and write the rack at a reasonable rate, it will be proof of concept. The Freeduino clocks at 16 Mhz and should be able to test SPI at 8 Mhz. With setup time, etc. actual throughput will be less but should scan 16x8 fairly rapidly.

Regards
cww

 

You might want to look into how you would interface this with a computer, whether that's a PC or another ARM board like the Panda. It would be nice if you were able to just plug it into a USB port and read from and write to it as if it were a file.

 

Hi Michael

I'm not sure what you're suggesting. For this stage, the FD (I get tired of writing Freeduino) would be standalone except for programming. I would write some sort of loop to read and write to the PLC SPI bus. You are right in that once it works, this would get pretty boring. I suppose I could then reprogram the FD to talk with a PC on the serial port to do something useful. This could be acting as a remote IO rack, for example. To do that right would probably mean writing a Modbus implementation. And to work fast and asychronously would mean writing real time code on an 8 bit micro. I think I overcame that obsession with the Z80 long ago. There is a reason that I want a Linux capable processor. But, mid-tirade, I revisit your comments and wonder if we're synching. The XXXPLC is intended to turn a SBC into a PLC. The link is the SPI backplane. How the SBC talks to the outside world depends on the SBC. For Beagle it would be USB, for Panda it would be Ethernet. For the FD it can be either RS232 or at greater cost, USB. I prefer Serial for the test case. Younger folks might prefer USB. For the test case or for a standalone PLC serial is fine. If I were to do the remote IO thing, I think Ethernet would be the way to go. What were you thinking about?

Regards
cww

 

I was thinking in terms of being able to use the I/O with either a Panda board (or some other similar ARM board), or with a PC. The more ways you can use it, the more useful it is. Ultimately, you would like to have a PLC, but I think that any practical "PLC" is really going to be a soft logic system that runs on either a PC or an ARM board that runs a standard Linux distro (like Debian). It would also be useful for things like automated test systems where an ordinary PLC falls short, but you don't need DAQ board style high speed buffered I/O.

I've been giving it some more thought. The problems with RS-232 are that while the initial implementation on a simple field device may be easier, it's harder to actually *use* because: a) RS-232 ports are rapidly disappearing from off the shelf hardware, b) it's slow, and c) it can be difficult to use because of timing and configuration (baud, parity, etc.) issues.

Ethernet is fast and easy to use, but it's much more difficult to implement on the field device unless you have a complete 32 bit CPU and Linux stack.

USB has relatively low hardware requirements from the field device and you can get single chip SPI to USB converters. On the other hand, all of the existing USB digital or analogue I/O that I know of uses a proprietary (and closed source) protocol, so it's poorly supported from a software perspective and replacing any of it later is a big problem.

What would be nice is an I/O rack that uses USB, but also uses an existing standard device profile so that you can just plug it in and it shows up automatically in "/dev" (or "/mount", or whatever). Most PCs and many 32 bit embedded boards have multiple USB ports and you may be able to use USB hubs, so you should be able to add as many local racks to a system as you could reasonably want to use.

Perhaps you could emulate a USB to serial converter device, so that the computer *thinks* it's just talking to a converter, while in fact it's talking directly to the device with no intervening RS-232 link. That way you just plug it in and it's there. It ought to be very fast because there's no actual RS-232 conversion involved. You wouldn't actually truly emulate all the features of an RS-232 converter, you would just have the device claim that it was one and accept the data as if it were.

If you used Modbus/RTU as your application protocol, then existing software that supports Modbus/RTU could talk to it so long as you could point it at "/dev/ttyUSB0" (or whatever). If you want to cover applications where you really do need Ethernet, then the solution to that is to add a Panda board (or something similar) and call that the "communications adapter module". The cost is not unreasonable compared to what the equivalents are for regular PLC remote rack I/O adapters.

I haven't looked into the details that's required to implement this idea, but I think it covers most of the angles. I looked over the typical device profiles on "http://www.linux-usb.org/usb.devices.txt", and USB to serial seems to fit the bill the best. The basic idea though is to make the I/O rack interface emulate some sort of standard USB device that already has support built into every modern Linux distro out of the box.

 

I shouldn't even be thinking about this as there lies the road to feature creep..... I wonder if it would be possible to emulate a very small stick drive. This would only be attractive if you could bypass all the caching and any wear leveling, etc., etc. and just R/W a file that is a register map. I personally don't like USB much and haven't bothered to understand the internals. It's sort of like sockets, the idea is just to use it. And to do something reasonably Open and standardizable would mean something like Modbus/USB (tm.):^) It would be closer to Modbus/TCP than Modbus RTU and one of the easiest ways to do it would be to implement a TCP like layer. Anyways, the beauty of doing the project this way is that once I get what I want, anyone can write whatever they want on any platform they want as long as it does SPI. I also wonder if SPI could be extended to USB distances, with proper controlled impedance transmission lines and back matching, etc. and save a lot of trouble. Too bad PCs don't have a convenient SPI port. You can bit bang the parallel port, but that's slow and lacks elan and the PP is next on the list to be eliminated by the duopoly. While we're on the subject, for those following along, I may hack the backplane down to a 4 slot, minus the level shifters for the low voltage SOC I/O, for the simple reason that the full 8 slot backplane will require that I shell out $65 and a 4 slot will be about half of that. While the DorkBot prices are low, getting 3 boards at a time works against you when you only need one. If someone wants an untested, unproven, backplane at cost I might be dissuaded and do the 8 slot first, but I need to conserve cash. The IO cards will be pretty spendy too, at $44, but for those the qty 3 makes sense. Who knows?, this might be my automation swan song, I may need to migrate back to IT or electronics (or barn cleaning) just to get a job. Not many capital project starts these days.

Regards
cww

 

A couple of posts ago I said "it would be nice if you were able to just plug it into a USB port and read from and write to it as if it were a file". At that point I was thinking in terms of having it emulate a USB flash drive, which each slot being a directory, and each card having three files - one each for read, write, and configuration. You would just write to the write file to set outputs, read from the read file to read inputs, and read from or write to the configuration file to change card related configuration options (if there are any). The rack would look like a USB flash drive that was formatted as FAT, so when you plugged it in to a USB port it would just look like a file system.

Bit oriented inputs and outputs could be addressed via byte offsets in the "files" (with one byte per point). Analogue I/O could use 16 bit word offsets between points. Buffered I/O cards could be circular buffers (FIFOs) which appear as "files" with a fixed size (e.g. 2048 bytes for a 1 kilo-sample buffer of 16 bit words).

That sounds really nice in theory, but unless someone has already done something similar that you could copy it sounds like a lot of software to write. USB drives just read and write sectors, and you need a file system on top of that. That means you would need to emulate the sector read/write commands, plus add an emulated file system on top (admittedly FAT is pretty simple though).

That would be fantastic if you could do it, but in the post following that I had second thoughts about it and suggested the USB to serial converter emulation instead. That sounds like a lot less work on the device firmware end. It adds some extra complexity on the PLC/PC end, but that would involve using Modbus, which shouldn't be a real problem. If I'm wrong about the relative merits of the two and the file system idea is simpler, then that would be the better option.

There is another option which is the "Test & Measurement Class". You can find the specs here: http://www.usb.org/developers/devclass_docs
These are supposed to get mounted as: /sys/bus/usb/drivers/usbtmc/devices/*/interface_capabilities
and as: /sys/bus/usb/drivers/usbtmc/devices/*/device_capabilities
The problem with that option is I don't think it really provides a complete answer, and I don't think that application level drivers are included in a standard distro. From what news I have seen elsewhere, the whole test and measurement standardization area is a bit of a mess with progress being driven by the major vendors who are moving at a glacial pace (due to their own bureaucracy, not by intent).

As for extending SPI to USB distances, well I was under the impression that was more or less what USB was created for (to extend SPI or I2C outside an enclosure).

As for implementing it as Modbus/RTU or Modbus/TCP, I was thinking that existing Modbus/RTU libraries will open a TTY and so could be pursuaded to talk to a USB serial converter, while existing Modbus/TCP libraries will want to open a socket. The only advantage to using Modbus/TCP would be that you wouldn't have to calculate the check-sum and so could avoid some software overhead. I could write a application level Python library to use "Modbus/USB", but the idea of using Modbus was to make it compatible with as much existing software as possible. If you want to support *both* Modbus/RTU and "Modbus/USB" that's great, but really, you need to start with a focus on the user and derive the requirements from that point of view.

As for a 4 slot back plane for the initial system, there should be nothing wrong with that so long as the design can be extended to an 8 slot version. You would really want to eventually have versions for both 4 and 8 slots anyway.

 

The reason I think it would have to be closer to Modbus/TCP is that there would be no benefit in converting back and forth if one had to respect all the timing rules in serial Modbus. I could be wrong, and I'm sure Lynn could chime in, but I think packet transport would work better than time dependent serial transport. But any of the above would be a lot of code to write, especially on top of an 8 bit processor. I think one of the original respondents had suggested that I embed an ATMega or the like for field IO. I think plain old Modbus would be plenty challenging on the 328. Actually the FD can be had with a USB port,so it would come around to protocols and speed. But fortunately, this can be a discussion for later. I ordered the silicon today so I can breadboard it. I agree that a 4 slot version is not a waste as 64 points are plenty for a lot of applications. I'm really on the fence about the level translators, I suppose I have to include them to be compatible with any of the ARM boards, but I'll need to drop in some messy holes to bypass them for 5 volt processors. And they cost real estate. The code for the arduino loader is OSS, so I can look and see what can be done with the ports.

Regards
cww

 

Today there has been a posting in our forum that pvbrowser is running at an ARM singleboard computer.
http://tech.groups.yahoo.com/group/pvbrowser/message/1264

It is a
http://www.friendlyarm.net/products/mini2440?lang=en

Is this post from you ?

 

No, I can't afford that card at the moment either, but it is a candidate and reinforces that processors that will run Linux for easy development are getting quite competitive with development with the deep embedded approach unless the volumes are high. I did see that you can get that card with a touchscreen and camera for the price of a BeagleBoard. Aside from the PLC project, this would make some machine vision applications fairly easy and extremely cost effective. 1.2 megapixels is plenty for most MV applications. It's an exciting time for cheap high function development. One thing that I haven't seen is the midrange. That is, a less expensive, high power, processor without all the bells and whistles. But, that's to be expected when handheld mobile devices are paying the freight. I didn't see SPI drivers for that board either, but I'm sure it has hardware support. To really leverage the power of OSS you need a board with a large community behind it also. The difference between a board that runs Linux and a board that run Linux and has all the drivers you need is huge.

Regards
cww