Printable View
Thanks for the brilliant info. I'll definitely check out those microcontrollers and have a go at programming one, if only for my own amusement.
I wonder if RS-232 fast enough for my purposes. I guess so since I'll have quite a large window (300-400 ms) to receive the result from the PC before the action has to be carried out.
The TCP-IP option sounds attractive, but I guess it's on a much more expense microcontroller.
Guys, thanks again for all the useful info.
Ben.
I, too, support the proposal of a microcontroller.
You can never be completely certain Windows won't 'pause' while it does something 'else' - destroying your timing.
That said, we see games responding to 'real time' on PC's, albeit where a brief pause doesn't mean something destined for bound Chicago doesn't end up in the bin for Milwaukee, but....
If you can get an interrupt, or perhaps respond to an interrupt from the serial port (see the serial port examples in MSDN for NT), you could fire your routines based on that with very high response time.
I still don't think I'd devote a Windows machine to industrial control, but since you're already almost there with what you have, you could try it to see if it's workable for you, while you wait for a microcontroller to arrive.
The idea would be, instead of polling, you'd wait on an interrupt from serial data.
As long as you have complete control over the Windows machine (so you know someone doesn't launch a browser to check email :) ), and assuming you don't have multiple streams of data firing off several threads all pegging the CPU, it might even work.
It's that might part that gives me pause....
Hey guys,
You've all definitely given me food for thought, and I'm seriously looking at the microcontoller route - I hope I can get it up and running quickly. It's a little intimidating since I've never used one before.
From looking around, I like the look of the Philipps LPC2138 - it may be a little over the top for what I need, but I'm fairly sure it can do what I need it to. I'm about to get this development board to experiment with (or even integrate):
http://www.olimex.com/dev/lpc-mt-2138.html
What do you think?
Chris, I looked at the controllers you recommended, but I think I'll be able to get started easier on the LPC2138.
Sorry if this is going off topic a bit.
Thanks.
Ben.
I understand this. Indeed, the first time you get a micro up and running can be a difficult step. I see that your selected board comes with samples. These should be of great assistance.Quote:
Originally Posted by shoppinit
Also take a good look at the term JTAG, a synonym for OCDS (On Chip Debug Service). OCDS (JTAG) is a realtively new (within the last 5-10 years) form of hardware support for debug systems. OCDS allows host source-level debugging within moderate costs. If you go the microcontroller route, then you need a monitor program or, better yet, OCDS interface. The only problem with OCDS is finding good windows software for source-level dubug.
You might really want to take a look at some of the products offerd by Keil (an ARM company). I am certain that Keil manufactures an ARM7 starter kit. And Keil offers truly state of the art debug support for micros, and the evaluation stuf is just the same tool chain, just with code-size limitations. The GNU stuff for microcontroller applications sucks!. Using this GNU stuff for µC's is like taking a walk in the past about 25 years ago (groovy man)...
Looks fine. It made me want to buy it...Quote:
Originally Posted by shoppinit
Not off topic at all as far as I'm concerned. This is actually the right way to go for real time interfaces.Quote:
Originally Posted by shoppinit
Good luck with your developments.
Sincerely, Chris.
It does for our company. We track items on conveyors using Windows XP Embedded. As long as you can tolerate an indeterminacy of plus or minus a millisecond or two then you can get away with it. The only caveats are that you must run your app at realtime priority class, perform no disc activity and specify unique priority levels to each thread. ie Highest -> System timer, Processing, GUI <- Lowest.Quote:
Originally Posted by JVene
The downside is that if your app locks up then you can usually do nothing except pull the power cord!
Getting back to your attempt at a Windows-based solution, please think about this:
Instead of polling, re-write so that your thread waits on an event that's set to the signalled state by the app that updates the detection date/action. In other words, after your app updates the the detection date and the action-to-be-taken, it should also set an event to the signalled state. Then replace your "polling" thread with a thread that simply sits at a WaitForSingleObject, waiting for the event to be set. No polling is necessary, and you automatically get the fast response time that you need (within, of course, the thread-slice time of around 15 ms which you can never get around).Quote:
Originally Posted by shoppinit
If there are only a few different proximity switches (i.e., less than 64), then each one can set its own event. Then use WaitForMultipleObjects instead, which will automatically tell you which of the switches need action, without the need to through the entire p_list each time. Otherwise, each switch can set the same event, and you will need to go through your entire p_list like you do now.
Just a thought. I think you might be overly focussed on the imagined requirement for a 1 ms polling rate, and how to get that, when in fact your real requirement might be more simply phrased as "I need to do something quickly after the proximity switch is hit".
Mike
Another idea to try: Connect your proximity detector to ping one of the state pins on a COM port. (CTS or RI perhaps?) Then make a Com port object with a thread that waits for that signal to go high. Then you can start the thread to process that object and wait for the next one to show up. If you set that thread to a higher than normal priority, you should have no problem keeping up with object flow.
Hi Guys,
Thanks for those suggestions. I think I'm going to try *all* of the above solutions and see what happens :)
The problem with the serial port idea is that I have no problem detecting the object - I'm using a DIO board that generates an interrupt so I can know pretty precisely when the object passes the sensor. The problem is getting the PC to take action exactly X ms later.
In fact, my tests so far have shown me, as you say John@Wessex, that I can accurately take the action at the right time, but I use up a whole processor doing it. I'm considering going the quad processor route, too.
My concern is that one day Windows is going to decide to do something I've got no control over that throws my timing off no matter how much processor power I've got. I've got no virtual memory, 2 gig of RAM and the bare minimum installed on the HDD and yet I'm still seeing anomalies. I put in a loop to simulate processor load in another thread:
This should keep the processor busy for 50ms and 999 times out of 1000 it does to within a few nanoseconds. But occasionally, I see that it's taken 57ms. My only idea is that there's been a thread context change somewhere in there that's taken 7ms.Code:finish_date = start_date.QuadPart + max_analysis_time_ticks;
QueryPerformanceCounter(&date_now);
while (date_now.QuadPart < finish_date)
{
int i;
double bob = 0;
bob = rand();
for( i = 0; i < 4000;i++ )
{
toto = (1 / (sqrt(bob+i)));
}
QueryPerformanceCounter(&date_now);
}
QueryPerformanceCounter(&stop_date);
My gut tells me that the microcontroller is the way forward and my evaluation board is already on its way from Bulgaria. My only worry with this is the communication between the micro and the PC - I don't know much about serial comms.
All of your help is much appreciated, really. It's good that there are people like you out there.
Ben.
Well, that puts an entirely different complexion on things, and incidentally seems fundamentally different from what you said earlier:Quote:
Originally Posted by shoppinit
IT seems to me that there's a big difference between the two.Quote:
The window for taking this action is about 2ms.
If you need some mechanical action to take place exactly X ms after some other mechanical event, then Windows will almost always be the wrong answer since it's not a RTOS.
Your needs would probably be best served with a RTOS.
Mike
Sorry, the 'exactly' was more for illustration purposes. There is a window of 1-2ms for the action to be taken.
Ben.
I guess you meanQuote:
Originally Posted by shoppinit
Ben, the Windows multi-media timer, as I had described it in a previous post, is as close as you can get to the 1-2ms resolution in the response time running in Windows User Mode. I did post the relevant code for setting a multimedia-based timer event for setting a precise timer event in the future of the program.Code:X msec +/- 1 or 2 msec
However, only the following will guarantee the response time resolution:
1) RTOS running on the PC
2) running in Windows Kernel Mode (Ring)
3) a microcontroller solution
Sincerely, Chris.
I have sorta the same problem. I need to send serial commands every 400 Microsec. Reading here Windows will not be able to do it. Too bad since that requirement just got added and its only a small part of the whole program writing in C#.
I have never used a micro controller, so let me see if i got this straight.
PC ------------->Micro Controller >---------Hardware Device
The Board sits in betwee the PC and the Hardware? or its just straight controller card to hardware?
Your "picture" is correct. Most controllers communicate with the PC over either Serial or USB. In your case (and based on the "other" thread), you would be able to send higher level commands to the controller which could very accurately (usually as sub microsecond resolution) send the information to your hardware device.
The programming of the board should be fairly trivial, even with a learning curve I would expect it to be accomplished in a few days [myself or some of the other posters on this thread, could probably do it in just a few hours].
Take a serious look at it. Since this appears to be a work related project, the investment of a few hundred dollars to at least evaluate a solid robust solution should not be a problem....
Quote:
Originally Posted by TheCPUWizard
Well we have decided to go that route. However, i saw the list of boards in this thread, and i have a question.
Does these boards come with a serial driver / package already. My point is that, and i dont know if this makes sense in the micro controller world, can i just get board, and after setting it up, start writing the actual logic on it ( the functions, etc etc ). or i have to write the serial driver myself first in order for it to communicate with the PC?
THis is the idea .
PC ( GUI, user types in commands ) -------*Low speed serial / usb * -----> Board.( Takes the command passed by the PC, and send that command at the given microsend interval) ----------------*HIGH SPEED SERIAL*----->Hardware board.
So then again, do i ineed to write the package for it to communicate or it has something already built in ( something like the SerialPort class in .NET? )
Every board that I have wotrked with comes with the Compiler/Tools and a program for downloading to the board. Many of them come with a debugger also.
Once the controller is up and running, YOU will determine what the protocol for your program communicating with the board will be. There are typicaly sendchar/getchar routines in the boards runtime, and your PC program just opens up the serial port as normal.
Let me know how it goes...