Good morning! I am designing an updated control system for a local race track, and I need the timing system to have a resolution better than milli-second scale. Is there a way to access faster resolutions in soft PAC? I have looked at other PLC’s and I can only find milli-second timing, I am hoping that the soft pac can use the computer CPU timing that will allow microsecond timing. Thanks!
Hello JFdean,
Welcome to the OptoForums!
Because SoftPAC runs on a PC which usually has more processing power than a SNAP-PAC-S or -R series controller, many things can be done faster in your flow chart. However, that may not be the limiting/relevant factor here.
What I/O do you have, and what exactly are you timing? The spec of the module itself and the features you’re using (or have shut off) at the rack are likely more relevant in this case. Can you tell us more about your current hardware, what you’re measuring, and your specific timing needs?
Thanks,
-OptoMary
Good Morning! It been almost a year to the day as to when I posted this, but I am once again on the hunt for a new system for the track. I had an illness hit and sidelined me but all is well now. So here is the rundown. Right now, the track (a drag strip) uses a bunch of proprietary electronic boards in a DOS based PC from the early 1990’s. This system is hard to repair, hard to troubleshoot,etc. So we want to replace it all but we need to time the runs out to at least several digits because a “tie” cannot happen. Basically, the system has two through beam photo eyes in each lane at the starting line that determine when a car is pre-staged, and then staged. So the driver pulls forward into the first beam, and then inches forward into the second beam. When both cars are fully staged, the lights on the tree drop down to initiate the run. Then, there are reflective photo eyes in both lanes at the 60’, 330’ 594’ and the finish line at 660’ (this is an 1/8th mile track) So the inputs are very limited. The outputs are the lights on the tree, the win lights in each lane, and then the scoreboards which will just read an ASCII code to display time and speed. The problem is that we cannot have a tie in a race, so I need to be able to go out to .000000 or further in timing from the point that the car leaves the staged beam and then makes the 660’ beam (all the others are only markers, but the whole run’s time is very important) So if the car in the right lane runs 5.543 seconds, AND the car in the left runs 5.543, obviously this would be a problem. So I need to go well past the millisecond resolution. That way it will time and show say 5.5434687 seconds. I hope this makes sense? I love the idea of ripping all this old proprietary junk out and building a new system with a SOFTPAC heart, so please let me know if we can make this work.
SoftPAC isn’t going to be close enough to the IO to gain you anything and this isn’t something you can rely on ethernet for.
An EB1 on a rack will be able to respond faster, but not fast enough for what you want, as the lowest you can set the scanner interval to is 1 msec, and to get that speed you will need to be using digital events on the brain.
Maybe Mary knows a secret setting to make the scanner faster.
FWIW, I would be looking at micro-controllers for this task - something [B]without [/B]an operating system that you can count clock cycles for accurate timing - like a good old 8051 or an Arduino if you want something more modern.
You can then pull the data out over serial to a PAC if you would like.
Wow, well, I’m flattered by philip’s confidence, and I do know a trick or two but … before we get to any scanners or brains or controllers, don’t forget the I/O. For example, our SNAP-IDC5-FAST has a turn-on time of 0.025 msecs (with some fine print).
Also, forgive me if this is a silly question, but, what if you do go a few more decimal places – you could still have a tie there, right? I guess the odds of that happening drop off with each additional decimal place.
Anyway, I notice that our built-in on-time totalizers show 4 decimal places in the PAC Control debugger, but the manual for the related commands tells me: “The accuracy of the value returned is limited by the input module’s turn-on and turn-off times. Check the specifications for the module to be used.”
Good Morning! Yes, you could still have a tie, but it would be very unlikely. in the event that happens, the faster car gets the win. However, this track does a type of racing known as bracket racing where cars “guess” what their car will run and then the slower car gets a head start. for example… you and I are paired up to race, and I suspect my car will cover the track in 6.00 seconds and you think your car will do it in 7.00.( they always guess to the hundredth of a second). In this case, I have to give you a 1 second head start. This makes the racing VERY close and competitive with races almost always determined by a few thousandths of a second. It likely will go to the .000X digit at least once per day… and even further out a few times a season. Right now, the system will time out to .000000, but this is a little flawed because the I/O in the field cannot respond that fast. But, the timers will still run out that many digits when the signal is given. I guess it is as accurate as it can be, and us racers accept that the timing system is only as accurate as the technology will allow. So technically, this current system may only have a millisecond response from the I/O but it still displays and calculates on a timer running way out to lower the chance of a “tie” I hope this makes sense.Thanks for the feedback. I really appreciate it.
Also remember the difference between [U][B]accuracy and resolution[/B][/U], as discussed on [URL=“http://www.opto22.com/site/accuracyvresolution.aspx”]this page.
The example that I like is my bathroom scale at home, which displays digits XXX.X. However, I notice that last digit, only ever shows a .0 or .5 so the resolution is half a pound. But based on the numbers it keeps showing me, the accuracy is WAY off! 
However, when it comes to comparing two numbers, if the difference between the two (I think of polling results) is in that “margin of error” – then what do those numbers really mean?
Also consider what our 32-bit IEEE 754 floating-point values will show/hold there in their 32-bits in memory. You might be interested in this tech note which gets into significant digits which sounds like might be more of the issue here? For example, when you get to 1.677722e+7 and add 1.0, you’ll no longer see a change because 1.0 is too small relative to the whole number…
We do have 64-bit INTEGERS you can use in your logic, and there’s even this discussion of how to go from a 64-bit float to our 32-bit floats… but now I’m wondering, how are you displaying these values? Our groov HMI DOES support 64-bit floats! And Modbus direct to our Mem Map but I digress…
Mary,
If the brain will only scan the digital IO once every millisecond, how can you tell the difference in time between two inputs of less than a millisecond or measure a pulse of less than a millisecond?
For the IDC Fast modules - is the pulsing handled in the module itself rather than in the brains logic?
Just trying to understand the under-the-hood stuff better.
Only the higher-density digital modules (more than 4 channels) have any processing power/intelligence on them.
The R1 and R2 digital scanner runs every millisecond at the highest priority. It can only be interrupted by hardware interrupts like Ethernet, Serial, etc. If those are kept to a minimum or eliminated the system may provide accuracy as good as 1ms. For the fastest input detection (as of this writing), you’d use a SNAP-IDC5-FAST (0.025 turn on time). The digital scanner will detect the input state change, and start the timer w/in 1 millisecond for features like the the on-time totalizing I mentioned above (which happens in the R1/R2 rather than the module).
So while we [I]could [/I]show lots of decimal places for the “resolution,” the accuracy is a different story.
Good info!
Just to be clear – I meant the higher-density DIGITAL modules there. All our analog modules have some “smarts” to do things like cold-junction compensation, etc…
If 50uSec resolution is close enough, I think you can get there with opto22 hardware, BUT, you will need to use the older FactoryFloor software with the older G4 I/O and an older controller like the LCM4. The feature you need to use is not available on the new stuff sadly… The idea is to feed a pulse train into a input module configured as a counter, then read that counter when triggered by your lane sensors.
You will need a fast input module (G4IDC5K) configured as a counter with a 20KHz clock fed into it. **Note this is right at spec for this input module with a 25uSec turn on/off time, so testing will be necessary. Your lane trigger I/O’s will need to be on the same rack as the counter with “Read and Hold Counter” events configured.
I don’t know of any Opto22 brain hardware that would be able to respond to the lane trigger and get the count within the time frame Jfdean is looking for - there is latency there.
The hardware only scans the digital points periodically, so if two points changed 500 usec apart - the brain will see this either as changing at the same time or one scan interval apart. On modern hardware this scan interval only goes down to 1 msec. I doubt it was any faster on the legacy stuff.
The controller doesn’t matter - it is too far away from the IO (over a network) to make any difference.
Yeah, it looks like he is wanting greater than 1uSec resolution which just isnt possible. BUT, I do think that he could build a system with opto22 hardware that will accurately determine the winner with resolution close to 50uSec. It is a stretch, but I like opto : )
Take a G4D16R brain. From the datasheet we can infer a typical event/reaction response time for a single point of 250uSec (I would be interested to know if the microcontroller I/O is processed on interrupt or a timer ). Have one rack for each lane with each rack only communicating on interrupt (likely the last photo detector) to reduce brain processor burden. With this setup, any latency in the Opto22 system should be equal and will cancel out. It wouldnt matter if there was a 500uSec delay or 100mSec, as long as both racks repeat-ably experienced the same latency the winner would still be accurately determined. This would of course have to be tested!
To have an event configured as “read and hold counter” the controller absolutely matters. This feature is only available in FactoryFloor and firmwares of that time.
I wouldnt want to build a new system on old hardware though, so…
The controller doesn’t matter, not because of the features, but because of the latency (which will vary) between the controller and the brain. For what you are describing, the brain would need the read and hold counter feature.
Ah yes, you’re right. Read and hold counter is a brain feature. Thanks : ) So any new mistic capable controller should work in this scenario. Latency between controller and brain should be a non-issue.
A post was split to a new topic: Reading time in PAC Control