Control.com - Nerds in Control

My application requires digital I/O "Hand Shaking" response of about 1 mSec with VB.Net. I need some recommendations for DAQ hardware/dll combinations.

In the past, I have successfully implemented this type of system with VB6 and Opto 22 PCI-AC5. This is both expensive and difficult to debug.

I have also used Modbus TCP with Modicon I/O. But, this was only good for about 50 mSec.

Any recommendations?

Thanks

I don't think most common I/O networks will provide ~ 1 MS latency. Does Opto22 support the AC5 card with modern drivers for Windows and .NET? If not, try another vendor of parallel I/O boards, such as National Instruments or Measurement Computing. I think a PCI card with parallel I/O would be the simplest solution.

The Opto 22 PCI-AC5 appears to be just a 48 channel digital I/O board. You can get equivalents to this from Advantech, Measurement Computing, or NI for less than half the price.

As for getting 1 msec response time for a handshake on MS-Windows, I would be rather interested in hearing how you did this in the past. MS-Windows has a 10 - 15 msec scheduler resolution. In the past on this list we have discussed experiments showing random system delays an order of magnitude greater than that. Now with your new project you are going to add to this the DotNet software, with it's additional random delays while it does garbage collection. Perhaps you could tell us more about how you intend to accomplish this.

In VB6, I just referenced their DLL, set up a timer event like a PLC scan (read inputs, make decisions, write outputs). You tell it to read one input as the first index in an array and it actually reads all inputs and fills the entire array:

    'Read Inputs

    ErrorNum = OptoPCI_Direct_Unpacked_Read(DAQHandle, 0, InputValues(0))



    'Write Outputs

    ErrorNum = OptoPCI_Direct_Unpacked_Update(DAQHandle, 1, OutputValues(0))

    ErrorNum = OptoPCI_Direct_Unpacked_Read(DAQHandle, 1, OutputValues(0))

For the timer, I used the MB HiTimer that raises a reliable event every mSec.

As far as .Net, I am new to .net and thus far haven't found a way around the 16 mSec issue.

So, it appears that you have used one of the ordinary "high speed" timer controls which use the MS-Windows "multi-media timer". You won't get a guaranteed 1 msec response time with this method, as there are too many things which can (and do) interfere with it at random. The multi-media timer is intended for playing media in things like video games where the occasional glitch or stutter probably won't even be noticed.

If your handshake actually depends on being able to respond in 1 msec, then you either need an RTOS or you need to move the handshake response to some hardware which can operate independently from the PC. Some digital I/O boards can be configured to deliver reliable independent high speed handshakes. Depending upon what sort of handshake you need, something like that may be suitable.

If however all you want is to speed up the handshake most of the time (e.g. to save cycle time) without it being a hard requirement, then there are some additional things you could try. The multi-media timer tricks that some people had been doing with the old VB 6 and older though don't seem to be possible with the current version of VB (DotNet). You can try calling the old version as "unmanaged code", but I don't know if this will work.

What people typically seem to be trying to do for short time delays when using DotNet is to use a "busy wait" (a loop that just wastes time) while calling "QueryPerformanceCounter" to see how much time has elapsed. QueryPerformanceCounter is intended for use by things like code profilers and gives better resolution than the normal DotNet library. The problem with this method is two fold. First, it ties up the CPU at 100% usage while doing nothing, so it isn't good for multi-threaded applications. Second, there is nothing to stop MS-WIndows from de-scheduling it like any other process to let something else run like any other process, so it can only guaranty the delay won't be *less* than 1 msec.

I am also interested in those techniques :^) Had a pleasant surprise today working with a commercial vision/OCR system. Was in a timing screen and they had 40 microsecond resolution. I was very skeptical until I booted it and saw the first line.......Uncompressing Linux. Looked for all the world like your typical Windows app but extremely fast. Most users would never know the difference, and the IT types will have a cow when they find out. In the back door and on the network for 6 months with no fuss or bother.

From the EU, of course.

Regards,
cww

lol, awesome. I love well written Linux apps/packages (Knoppix, for example) - just hate trying to make Linux seamless. I like seeing OEMs do things like this. Funny, IT may or may not have a problem with an "appliance" Linux app if it has a web frontend. Like the Linksys NSS 4000 that I just bricked updating the firmware :(

----
Nathan Boeger
http://www.inductiveautomation.com/demo
Total SCADA Freedom

I actually like making Linux seamless because
you get the tools to do it. I've come to dislike
Windows software because it works the way
it works, which occasionally is well, and
there isn't really much you can do about it.
I'm sure most of us have just had to live with
a crappy, flakey, or inconvenient package for
years. Actually this is somewhat true for all
canned software, but even with binary only
software , there is a lot more you can do in
the Linux environment to make things work
better.

Regards
cww

Well, you're a diehard Linux fan, so it figures. I like the IDEA of all that you're arguing for, which is why I like using products where someone else has done a nice job. I've used Linux as much as (probably more than) the next guy, but every time I get a great idea of turning my favorite project idea into a Linux appliance it turns out to be a disappointing waste of time.

1. 1997, making a Linux based embedded computer in my car to play MP3s. Between quickly and safely starting up and shutting down the OS and creating a smooth interface (input and output) without a keyboard and monitor proved to be too much headache for me. :(

2. 2002, installing Linux on my laptop. My "successful" project. Took a half day of supergeek help to get the following working: Ethernet, wireless, printing, sound. We never could get the Winmodem to work - and it probably never will. This is significantly easier with many Linux packages now.

3. 2003, I have a huge arcade machine that's supposed to powered by a seamless computer running MAME and a frontend that can be controlled by the joystick and buttons. Too many frontend problems and issues with my specialized video card (that could display native arcade resolutions and output directly to an arcade monitor) made even my geeky friends from Linux users groups give up. Windows looks like crap (won't display properly) at around 240x200, but once you fire up the frontend all is good.

4. 2007, a project to make an automated bar (BoozeChimp.com, but the web site needs serious content upgrades). Considered using Linux, but decided to not even try because it took so much effort to do everything - especially when adding a USB webcam. I did start with a proof of concept Linux machine to drive the relays and run the control app, but ran into problems - gave up before troubleshooting much.

Side note: At 2 places I've worked, one high profile, we've had our Linux and Solaris servers hacked several times (I wasn't the main admin). We never had our Windows servers hacked. The closest with Windows was cheesy batch file "virus" that copied to shares that had a blank password. I might add that Exchange servers get hit hard when these email worms go around.

Bottom line - I guess I suck with Linux. I can't argue that it isn't possible to make it more secure than Windows (and boot faster, and so on). I just can't stop quoting my old boss that, "Linux is only free if your time isn't worth anything".

That said I still want to make the Knoppix/Morphix based HMI boot CD and I still plan on installing Debian on my new laptop with VMWare to run Windows virtualized.

BTW, I could have written a post this long with complaints about Windows.

----
Nathan Boeger
http://www.inductiveautomation.com/demo
'Design Simplicity Cures Engineered Complexity'

Linux is certainly not "free" as in total cost. There is still a tremendous cost as your examples properly point out.

Linux is "free" as in freedom, you can do what you want with the software and use whatever version you want.

All this freedom does carry certain costs along with it. You just have to weigh the costs and benefits of Linux and decide if it will work for YOU.

I have found for low volume industrial projects, it has not worked for me. It does work well for many people in server applications. It depends on how well it fits YOUR needs.

I would say that for many of us in the industrial arena, neither Windows or Linux really meets our needs. They both have major hurdles to jump. We just choose which is the closest match.

Bill

> Well, you're a diehard Linux fan, so it figures. I like the IDEA of all that you're arguing for, which is why I like using products where someone else has done a nice job. I've used Linux as much as (probably more than) the next guy, but every time I get a great idea of turning my favorite project idea into a Linux appliance it turns out to be a disappointing waste of time.
>
> 1. 1997, making a Linux based embedded computer in my car to play MP3s. Between quickly and safely starting up and shutting down the OS and creating a smooth interface (input and output) without a keyboard and monitor proved to be too much headache for me. :( <

I have seen it done, but _any_ embedded project involves
headaches. I doubt there is a really smooth way yet. The
nicest setup I've seen used laptop type power management
and simply slept for downtimes less than 24 hrs.

> 2. 2002, installing Linux on my laptop. My "successful" project. Took a half day of supergeek help to get the following working: Ethernet, wireless, printing, sound. We never could get the Winmodem to work - and it probably never will. This is significantly easier with many Linux packages now. <

A lot of that has to do with the fact that at least part of the
motivation for Winmodems
and Winprinters, etc. is that they _only_ work with Windows. I see it as
quite an
achievement (and a misguided effort) to RE the things to get them to
work at all
with Linux. But the Linux guys even run on an XBOX. It was getting hard to
find a printer that was useful with everything else and they are still a
pretty poor
example of engineering, but they served the purpose of diminishing the
value of
PostScript and other more open and universal printing languages. The
economics
of Winprinters share much with the economics of Windows. The landfills
are full
of Winprinters that are cheap to buy but incredibly expensive to
operate. Strange
that Windows users can see that.

> 3. 2003, I have a huge arcade machine that's supposed to powered by a seamless computer running MAME and a frontend that can be controlled by the joystick and buttons. Too many frontend problems and issues with my specialized video card (that could display native arcade resolutions and output directly to an arcade monitor) made even my geeky friends from Linux users groups give up. Windows looks like crap (won't display properly) at around 240x200, but once you fire up the frontend all is good. <

Yes, Windows is definitely the OS for playing games. :^)
Seriously, that is one area where money talks. Every hardware
manufacturer targets Windows for obvious reasons. And it's a
very few that will even release enough information to write
Linux drivers.

> 4. 2007, a project to make an automated bar (BoozeChimp.com, but the web site needs serious content upgrades). Considered using Linux, but decided to not even try because it took so much effort to do everything - especially when adding a USB webcam. I did start with a proof of concept Linux machine to drive the relays and run the control app, but ran into problems - gave up before troubleshooting much. <

It helps a lot to work backwards on stuff like that and start with stuff
that's
well supported. Partly the same problem as above.

But, those are all pretty much multimedia projects rather than mainstream
automation.

> Side note: At 2 places I've worked, one high profile, we've had our Linux and Solaris servers hacked several times (I wasn't the main admin). We never had our Windows servers hacked. The closest with Windows was cheesy batch file "virus" that copied to shares that had a blank password. I might add that Exchange servers get hit hard when these email worms go around. <

Yes, it is possible. It does usually require more than a script kiddie
to do it.

> Bottom line - I guess I suck with Linux. I can't argue that it isn't possible to make it more secure than Windows (and boot faster, and so on). I just can't stop quoting my old boss that, "Linux is only free if your time isn't worth anything". <

Fear not, MS is working very hard at making Windows hard to use.
They've come a long ways towards that with Vista.

> That said I still want to make the Knoppix/Morphix based HMI boot CD and I still plan on installing Debian on my new laptop with VMWare to run Windows virtualized.
>
> BTW, I could have written a post this long with complaints about Windows. <

Why don't you try all those projects with Windows :^)

Regards

cww

In a factory type environment that might be fine where you have a staff of IT and electrical control people on the spot. But in our case we have control all over the State, and possibly getting most of our users and operators to even understand Windows errors operations and crashes can be a pain. I can't imagine throwing Linux in front of them, "ugg".

As long as it was a embedded application such as a Web server for an intelligent switch, the reason I say that is because I am the only IT-Control-Applications person in our organization and I have enough hassles.

That can actually work both ways. I've found much less tendency to tamper with the system. If the users are doing what they are supposed to be doing, they might never know that Linux is being thrown at or in front of them, The vision appliance I was working on the other day is a good example. _I_ didn't know it was running Linux, just noted that it was very fast and stable. But except for that boot message, _no one_ would know. I can't see how it would inconvenience your users unless it crashes or needs systems level work. All they see is the application. If it stays running, what difference would it make what it runs on?

Regards
cww

Hi JJ,

Can you give me advice on the OPC.dll for VB.Net? I'm working on a slightly similar project as what you are working on. However I'm stuck with the .dll file. We could chat faster through an email if that's what you wish and my email is ang_shaun @ hotmail. com Feel free to e-mail me, if not we could just continue posting on this forum. :)

Shaun,

I'm not sure I can help. For my current application, I am trying a National Intrument's(NI) DAQ card with NI's DAQMX software. I had a NI USB TTL DAQ laying around and tried it with VB.net. It worked very well. In my test, it performed millions of "hand shakes" with out an error, each iteration taking about 6 mSec.

As for OPC, my only experience is using OPC to communicate with a SoftLogix 5800 system through VB6 using RSLinx. It was very reliable as long as you didn't expect speed. Trying to exchange data quickly resulted in lost data.