Have you published a benchmark for the speed of the Epic?
It is very hard to know what this CPU is capable of when trying to apply it to high speed applications.
I need an actual example of a benchmark and all the associated caveats to be able to make a reasonable judgement as to whether or not Epic is capable of pulling of any specific application.
My current example is where my client is asking if he can turn it into a flow computer for oil and gas applications. For those of you not familiar with this application, in the oil patch, pipeline companies transfer such large volumes that even the smallest error in flow computing becomes a big deal.
In this case my question is can Epic capture the end of a 10khz count rate to <1 count? This is assuming pac control, no other loads, and quadrature input module doing the counting with a separate quadrature input providing the counting start and stop.
After thinking about the CPU speed which I understand to be 1ghz, I realized the clock speed is 1 nanosecond. Therefore, operations should be happening in the sub microsecond region internally. Therefore, the questions are now, how much over head, and what is the backplane speed and is the backplane parallel or serial?
If serial then the backplane speed will be the bottle neck.
One more question I have is can the quadrature module be configured to use one of the inputs to trigger the counter to start and stop without getting the controller involved? If so, this would be really a big deal…
I am talking exclusively about Epic.
I believe in a previous response to one of my posts, you informed me that the CPU was a 1ghz processor. That should translate into 0.000000001 second per clock tick.
I should think since there are 1000 CPU clock ticks in a micro second, this would leave enough time for overhead to occur and still do a number of operations in the same time period. Is that an unreasonable assumption? Of course this assumes only internal operations, no external comms involved.
I fully understand that you are talking about EPIC, but I wonder how you decided this question and answer for SNAP-PAC?
My point is, you know full well that there are MANY variables that make this hard to give a black and white answer to, so EPIC, just like SNAP has some variables to work out.
Of course that is true, I am speaking of course about what is theoretically possible based on the numbers. This also needs to be qualified with “no other substantial load” and let’s say for argument purposes, 1 chart running, waiting for this event to happen.
Can you tell me about the backplane?
I guess I’ll have to ask, why is opto so reluctant to provide details regarding the operational speeds?
I can’t think of anything more important than this when considering almost any application, and certainly anything that requires accuracy dependent on the speed of the system.
Actually I am not asking for black and white, I am asking for details so one can make their own calcs as to the capability for a specific application.
So is it the position of Opto to say that “well we really have no idea of what our controller will do, so you should spend days of worth of hours testing to decide whether or not you should consider bidding a job or not” ?
To answer your question as a user - no, the epic can’t capture the end of a 10kHz pulse through PAC Control. (However I would expect the IDCIFQ module to have an accurate count of pulses at that rate since it is in the spec sheet - but to run logic in PAC Control between any two pulses at 10kHz will not be possible).
On my unloaded PR1 it takes 300us to read from the scratchpad. It was fairly consistent too (ranging from about 300us to 330us) To an IO module, the latency should be higher (I don’t have any modules installed on this PR1). The code is simple to test though - just change the scratchpad read to an IO point read.
Ok well if that is the case seems rather disappointing considering the clock is running at 1 ghz. You know if you’re going to put that much preload on the cpu of an industrial controller, then you ought to be using a 3 ghz chipset…or a multithreaded one.
The read to the scratchpad could be very misleading for a number of reasons…obviously the test with the IO would be better but even that has to take into account the time to start and stop your timer. I will have to try that. It seems that the idea of using this controller to do anything related to direct motion control is probably only viable on relatively slow systems.
I guess the IO test will also show glaringly how much of a bottle neck the backplane is. I understand it is serial (I assume Arcnet) but unless it is running at least at 1 ghz, it will be really slow. Too bad they did not learn the lesson of Pawmux.
If you are going to produce a quadrature module capable of 200khz on a system that cannot possibly service it, then you need to make the module programmable so that it can start/stop counting via the other inputs on that module as well as provide a pulse period for stop and start. Otherwise, what’s the point?
Why would there not be applications for this? If I am measuring flow with a pulse rate in multiple kHz, how else am I going to do it? I don’t care about the time between pulses (which I guess your application does). If I want to know the total flow over the last minute, then I only need to read the counter once/minute - no issue on a PR1 or a SNAP controller.
The 8-9 usecs seems like a lot of time considering the clock speed…?
If USB it the buss that could be good, but my guess is they started on this before 2014 when 3.0 came out…therefore they might be using 2.0 which means at best they will be at 480 mhz. Hopefully they are at 3.0 which gets it into 5ghz territory. Since it is serial so 1 bit per clock tick (not quite actually).
That’s true but that is literally the only way you can use it. Is reading a water meter the only thing Opto is capable of? How about something more sophisticated?
I mean really, todays encoders are capable of millions of ppr, much less a couple of khz. I don’t expect to read those but it goes to making my point that these are not speeds to get excited about in industrial control these days.
I know this is a vary old question but this may help someone in the future. I think I understand what he’s talking about I have several years of experience in the oil and gas industry this card should be capable of counting pulses up 200khz most oil or gas meters send a 5khz pulse for max rate GRV-IDCIFQ-12 module.
I plan on investigating the capability of the card in the near future using 6 high speed pulses generators. The plan would be to setup one pulse generator at 5kz let it run for 24 hours and see if the totals match on both counter and Opto. Then do a second pulse generator on two inputs at the same time all the way up to 6 inputs at the same time. My guess is the Opto can handle it. I’ll update this thread when I’ve done that. If I’m right all you need to do are the math calculations on oil or gas to get your volume combined with temperature and pressure and you have your corrected volume. I’ll be doing this in Codesys 3.5.
The problem in this application is that the Oil & Gas industry pipeline custody transfers actually look at not only the number pulse counts, but way more important, they look at the fraction of the last pulse in the total count, and do so with exceedingly ridiculous resolution.
This is because the volume flow through a 32" pipeline is huge, or even a 12" line. Therefore the comparison pulse generator that is used to count the pulses, has to be something like 100 folder higher rate to get the resolution and accuracy they are after. In addition, these pulse interpolation systems take into account the temperature and the pressure into the calcs.
This is all based on an API specification, both the requirements and the methods used. I think the unit that we are using has a clock frequency of 10 mhz.
The way they do the process is by recording the pulse counts from the meter under test, and then with a very fast start flag photo eye, they mark the fraction of the starting pulse, and then mark the fraction of ending pulse, and the calc the total fraction of a pulse plus the total number of pulses. In the case I’m working on they are using a Kollmorgen 14hp servo drive to move a piston through a 7.75" cylinder and the start and stop flags are mounted on the guides.
To your reply, yes, Opto is capable of measuring most pulse meters probably more accurate than the accuracy of the meter itself. The problem I have met in the past is that if you are monitoring and trending a flow meter, you’ll need to report the flow rate on at least a one second basis for a regular update. However, the flow total, of which the accuracy is dependent on the fractional pulse, needs to be updated a seldom as possible to improve accuracy. Therefore, my approach has been to use two channels of the IDC-Fast module, one for total and one for rate, just parallel the connection. You could also have two totals that are generated off the totals input, one that gets updated quickly, and one that gets updated only once every 24 hrs or whenever the flow drops to zero.
