IO Warrior Limitations

kking · Post by **kking** » Fri Dec 08, 2006 2:57 pm

Hello everyone. Just a heads up, this will be a lengthy first post of mine. First of all, I've been working with this IO Warrior for about a month now and I've learned quite a bit about it during that time.

However, it seems that I'm running into a limitation of the board, the computer or maybe just inefficient code. I've got a pretty good idea where the problem is but I wanted to ask about the limitations of the IO Warrior 40 chip.

Currently the project that the IO Warrior 40 chip we purchased will be used to control life cycles on our pneumatic valves. We have proven the board will drive a relay (through some fancy electronics) to turn our valves on and off at the specified rate. These valves will need to be held on and held off for a specific amount of time, and doing this over and over until the valve dies. However, it seems we're finding a problem when we hook up the oscilloscope.

We're noticing fluctuations in the times in the on and off times which means something isn't right. We are running a very simple program which turns a pin on for a specified time, and then off for a specified time. Let's say we turn a pin on for 100ms and off for 100ms. The total time it's on and off should be 200ms, but its actually anywhere from 200-215ms. The oscilloscope shows this and when we turn on a nano system timer in Java (JDK1.5 incase you were wondering) it shows the same thing. This leads me to believe the problem is in our program / limitations of our computers, something outside of the board. Even so, I wanted to ask a few questions regarding the board to make sure I'm not going to run into another problem later.

Now that you've got some background information, my questions are:

1. Has anyone tried to do real-time programming with the IO Warrior 40 chip to be accurate to under 1ms?

2. Are there any known limitations concerning response times when it comes to the IO Warrior 40 chip?

3. Are there any recommended programming languages when it comes to doing real-time programming? Currently I'm using Java and I'm having issues getting the times down.

That's all I have concerning the board. Now onto some programming questions that might be more suitable for a programming board, but since it's for the IO Warrior 40 chip I didn't think it would hurt to ask them here.

Some background info concerning our programming environment. This application is being developed in Java using NetBeans IDE with JDK 1.5 on a Windows XP computer. We have successfully ported this program to a ubuntu linux box. All of the following has been consistent on both operating systems, so we do not believe either one to be a significant factor in any of our problems, but I am willing to try any suggestions on either operating system. Our ultimate goal is to have this program running on the ubuntu linux box, but it is not an end-all-be-all requirement.

The closest I can get this program to consistently run in "real time" is within about 12,000 nano seconds. That's pretty darn fast and for what we're doing is acceptable. However, when doing this, I can only run one thread at a time due to the method I'm using.

As stated above, the current problem we're having is there is a 1-15ms delay when turning pins on and off (total time from before on to after off) which is viewed both on an oscillioscope attached directly to the board provided in the IO Warrior 40 Starter Kit. Originally we thought Windows XP not allowing programs to talk directly to the hardware was the problem, but now we do not believe that to be the case after successfully porting this program to linux and after turning on a nanosecond timer to view the actual start and stop times within the program itself. We now believe the program to be the cause of the delay.

We've traced the problem down to how we're timing to hold the valves on and off. The first method we used was doing a Thread.sleep(time_to_sleep). However, we found out this lowers the priorty of the thread and actually causes a longer delay that specified. In addition to that, it's also inconsistent on how much longer the delay is. And in addition to that (yeah it sucks, lol), it gets worse as you activate more pins. The delay is only 1-2ms when only 1 thread is running, but can jump from 1-15ms when 32 threads are running (yes, the oscilloscope dances). It ranges anywhere from 1-15ms added onto whatever you told it to wait. Since Thread.sleep causes the thread to be put into a lower priority, we tried to make every thread a high priority, and in windows we even raised the priority of the java program that was running. Neither of these seemed to have any effect on the delay times.

The next method we tried was creating our own "sleep" function. We created a function that used the same input, time in ms, and then retrieved the current time in nano seconds and then did a while loop until the time was greater than or equal to the specified wait time. We found this method is actually faster and we consistently are accurate within 12,000-6,000 nanoseconds. I believe this would be acceptable for our test enviornments. I think we have more of a delay within the relays than 12,000 nanoseconds. However, this method also maxes out the processor and limits you to one thread. When we ran two threads using this method, the wait time was doubled. We tried to run all 32 pins using this method and it pretty much locked up the computer.

Does anybody have any suggestions on where to go from here? Any ideas on other programming methods to try? I'm open to any and all suggestions and willing to try just about anything on either Windows or Linux.

Thank you for reading and thanks in advance for any/all help you can offer. If we ever get this working successfully with the IO Warrior board I'll post all the details on the problems we had, the limitations we found, and how we solved them so others can benefit.

Guido Körber · Post by **Guido Körber** » Fri Dec 08, 2006 3:49 pm

Relays usually switch in dozens of milliseconds, except for very small reed relais that can go into the kHz range.

The jitter in the timing you are seeing is the expected latency due to the USB protocol. IO-Warrior40 is a low speed device, as such it gets polled every 8msec and data transfer to it depends on the host controller type. If you computer happens to have an OHCI host controller the transfers to the IO-Warrior take about 300microseconds, UHCI (which is in more widespread use) takes 3milliseconds.

If you are also reading back the data from the IO-Warrior you fall into the 8msec latency.

If you need more consistent and faster transfers rates you should switch to the IO-Warrior56 which uses USB full speed. It does have a consistent 1msec latency independent from the host controller type. But there is no way to get below the 1msec granularity as USB does not gurantee when in a 1msec frame your transfer will take place.

wayoda · Post by **wayoda** » Fri Dec 08, 2006 4:11 pm

A lot of information in your post but I'll try my best:

Here is the bad news right away:
The variation in the delay your measuring cannot be avoided or compensated by any nifty programming techniques or thread tuning.

It's just the way Low-speed USB devices like the iowarrior work.
Its also no a matter of the OperatingSystem your running.
I can only speak for Linux (but it should be roughly the same for windows). When your application sends a report to the device its actually handed over to the USB-subsystem of the OS. There it is scheduled to be send down the wire by the USB-subsystem. For an IOWarrior40 on Linux the call to the write-function will return after a minimum time of 4.5 milliseconds. I was never able to write any faster. AFAIK by that time the IOWarrior has accepted the report, but the data hasn't reached the device. The hardware of device itself might add some more delay until the IO-Pins have actually changed the output level. You will probably get a more detailed explanation about this from somebody else in this forum.

Now for your questions

1. Has anyone tried to do real-time programming with the IO Warrior 40 chip to be accurate to under 1ms?

Realtime programming on an OperatingSystem which is not a Realtime OS cannot be achieved.
The OS alone decides when its time for your applications process to have access to the processor. Realtime Linux exists but I have no experience with it (and it won't solve your problem).

The magic number for the IOWarrior24 and IOWarrior40 is 8 milliseconds. These chips will never respond faster than this on reading. Writes seem to be faster but as I said I do not know when your data actually shows up at the outputs of the IOWarrior.

The magic number for the IOWarrior is 1 millisecond on read and write. You will never be able to go any faster than this with an IOWarrior on Linux.

2. Are there any known limitations concerning response times when it comes to the IO Warrior 40 chip?

see above.

3. Are there any recommended programming languages when it comes to doing real-time programming? Currently I'm using Java and I'm having issues getting the times down.

"C" is supposed the be the fastes language. But as mentioned before your limit is the specification for devices on the USB-Bus, not the programming language or the OS you're running.
Since we talk about milliseconds Java should be fine for your project.

BTW the times you measure within a Java app are not to be taken too seriously. There is alwways a chance the Garbage Collector kicks in somewhere and you not measuring your application speed anymore but rather the cleanup process running in the background. Stay with your scope for measuring timespans.

Eberhard

kking · Post by **kking** » Fri Dec 08, 2006 4:14 pm

We're not reading any data from the IO Warrior yet. We're just writing. I haven't seen a 3 ms time delay. When only one thread is running it can be accurate to the millisecond. I must have a OHCI host controller.

I firmly believe the problem is rooted in our program, but I don't know what to do about it. I was hoping someone here has tried to do real-time programming before either with this board or on a different project. I did want to find out what you told me though.

Also, that is good to know about the IO Warrior 56. We might upgrade to that one if we find out the 40 won't perform to our needs.

Thank you for your reply.

kking · Post by **kking** » Fri Dec 08, 2006 4:30 pm

I realize there will be delays in the hardware, but I would imagine they would be fairly consistent. As long as they are consistent, and we don't try to go faster than those delays, we should be ok.

For example, if it takes 8ms for a relay to respond. Our program says turn on for 10ms. After 8ms, the relay finally turns on. 2 ms later the program tells the relay to turn off. 8ms later it finally turns off. I'm not an expert on electronics or relays but logically that sounds like it would work (or maybe its just a pipe dream).

When I say "real-time" I don't mean it in its truest form. What I mean is accurate within 1 ms. It must be possible to do. Even if its not with our current setup, it has to be posssible.

The delays aren't a problem, as long as they're consistent. It doesn't have to be < 1 ms from program to valve, but it does need to be < 1 ms difference per cycle. I realize we may not be able to run a valve faster than 8ms or 10ms. As long as we don't try to run faster than anything in the system can respond, I think we'll be fine.

Guido Körber · Post by **Guido Körber** » Fri Dec 08, 2006 4:38 pm

The output delays to the IO-Warrior should be consistent to within 1msec. As I already wrote you have no control over where in a frame the USB places your transaction and a frame is 1 msec.

Thoug how repeatable the switching times of a relay are depends to a large degree on the relay. The bigger they get the less accurate is the switching going to be. Also turn on and turn off time is likely different. If you need consistency there you should go for semiconductor relays.

wayoda · Post by **wayoda** » Fri Dec 08, 2006 4:48 pm

kking wrote:I realize there will be delays in the hardware, but I would imagine they would be fairly consistent.
...
For example, if it takes 8ms for a relay to respond. Our program says turn on for 10ms. After 8ms, the relay finally turns on. 2 ms later the program tells the relay to turn off. 8ms later it finally turns off. I'm not an expert on electronics or relays but logically that sounds like it would work.

You would have to tune every delay cycle for each relay though.
I have experienced varing delays from specific relays that came from the same production charges. (Big ones though that switch motors).

Relays wear out (get slower), sometimes quickly others last for years.

Why not drive the valves directly from some more electronics that avoids the mechanical jitter?

Eberhard

wayoda · Post by **wayoda** » Fri Dec 08, 2006 5:07 pm

Guido Körber wrote: If you computer happens to have an OHCI host controller the transfers to the IO-Warrior take about 300microseconds, UHCI (which is in more widespread use) takes 3milliseconds.

So at least I learned something today. I tried an OHCI controller and got down to 1 millisecond for writes to an IOWarrior40 on Linux and Windows.
I apologize for the false information about the Linux USB timing.

Eberhard

kking · Post by **kking** » Fri Dec 08, 2006 6:33 pm

wayoda wrote:Why not drive the valves directly from some more electronics that avoids the mechanical jitter?

Some valves require different voltages and amps than others for one. Second, they all require more output than this board can provide.

We could barely drive the relay with the output of the board. (we had to get fancy with some electronics) Otherwise i'd rather do that.

Guido Körber · Post by **Guido Körber** » Fri Dec 08, 2006 6:40 pm

???

I would not expect the IO-Warrior to be capable of directly driving a relay of any significant size. You need a driver stage in any case, but that is normal in electronics. Between processing and output you need the appropriate drivers.

There are solutions for solid state driving of virtually any size of load, even if your load is the motor of a train engine. But you may have to cascade some driver stages to be able to control a really significant current.

In your case it looks like you will have to look for solid state relays, or semiconductor relays as they may be called too. There are some available that switch mains power from a CMOS signal just like the IO-Warrior does provide.