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.
