Looking for a automation controller board for this task, fast analog I/O, 25us cycle time

many of these requirements look more like constraints or solutions, for instance, the RAM 2GB, 2GB Ethernet ports, these are solutions, what is the requirement driving them

you specify 25uS loop time but also 100,000 samples per second for ADC, most real world scenarious do not needc even close to this ADC speed so more details os to why this fast would help

If I take all your requirements as a whole (Even though some are solutions, not requirements) then it would tent to lead me to a distributed processing solution, for example, there is no way a PLC will need 2GB Ram so I would assume this is for other processing requirements outside the actual control systems.

the 25uS requirement tells me someone is thinking of a PLC or other industrial controller as this is typically how they are specified so I would come down on using a uController like an ATMEGA328 / ESP8266 / Sitara or something as the control for the ADC / IO etc and pehaps a Raspberry PI / BB / Other Linux based Embedded board for the higher level master control

Please provide more details if you want a better answer

Well that's the thing that's aggravating for me as well. These are people who are good at certain types of engineering, but not embedded control, so presumably they want me to handle this. I know the requirements don't make a great amount of sense.

Here's is what the system has to actually do, we have two devices (I can't go into what they are) which feed power into a system, their power output is controlled by a 0-10V signal, the state of the system which changes proportionally to the energy applied is measured by a sensor with 0-10V output. The response is a chemical reaction and it's rapid, the entire process takes about 2 milliseconds. So logically a PID to control it has to cycle fast. Experimentally they had determined that they wanted an update cycle of 25 microseconds. There are two sets of these inputs and outputs running at once, so there are two PID loops.

The memory requirement is because the cycle happens repeatedly with parameters for the curve and endpoints in a huge array. Based on the data that it would hold I calculated that the array needed to be about 300 MB in size so I noted down a spec of 512+ MB because that's a nominal amount. It needed to reload that array between stages during which another part of the process would take at least 14 seconds. So in my own notes I noted that it needed coms with the computer that could handle that load in that time, 300 MB in 14 seconds is doable in a lot of ways, so I wasn't too concerned. 10 base T ethernet can handle this at 100 MBps. They also wanted it to report process variables all in real time, that totals 12 bytes, at a 25 microsecond cycle (40 killohertz) that's only 480 kBps. 10 base T is fine there too. So I wrote down the spec and figured I'd probably use 10/100 because it's pretty common and some overhead couldn't hurt, considering it's cheap.

So up till that point in the first meeting I think their requirements make sense. But even before our first meeting was over they specified that they wanted Gigabit ethernet. I explained that it might not be needed, but ok.

My next meeting was to tell them about the controller and firmware architecture I had selected. I had chosen an SBrio-9637. It has the speed, it has 512 MB of memory, a 667 MHz processor, analog I/O that is fast enough and runs at 0-10V. At this point I was told they didn't want a PLC, wanted atleast 2 GB of ram, and that it should have two gigabit ethernet ports. Not for any new requirement, just do do what is outlined above. Also that they "don't want a whole other PLC" in the system. Particularly annoying is that while I put in my contract that changes to the requirements will require an adjustment in my price, it technically doesn't say that arbitrary changes to the specs cost extra. I don't desperately need the work, but they are paying me a lot and it is a bad idea for a contractor to blow off clients, even if they are being a bit unreasonable, (and a little condescending, but I won't go into that).

But back to the original point, I ordered an SBrio anyway. I figure what they want is something that does the job.

Well that's the thing that's aggravating for me as well. These are people who are good at certain types of engineering, but not embedded control, so presumably they want me to handle this. I know the requirements don't make a great amount of sense.

Here's is what the system has to actually do, we have two devices (I can't go into what they are) which feed power into a system, their power output is controlled by a 0-10V signal, the state of the system which changes proportionally to the energy applied is measured by a sensor with 0-10V output. The response is a chemical reaction and it's rapid, the entire process takes about 2 milliseconds. So logically a PID to control it has to cycle fast. Experimentally they had determined that they wanted an update cycle of 25 microseconds. There are two sets of these inputs and outputs running at once, so there are two PID loops.

The memory requirement is because the cycle happens repeatedly with parameters for the curve and endpoints in a huge array. Based on the data that it would hold I calculated that the array needed to be about 300 MB in size so I noted down a spec of 512+ MB because that's a nominal amount. It needed to reload that array between stages during which another part of the process would take at least 14 seconds. So in my own notes I noted that it needed coms with the computer that could handle that load in that time, 300 MB in 14 seconds is doable in a lot of ways, so I wasn't too concerned. 10 base T ethernet can handle this at 100 MBps. They also wanted it to report process variables all in real time, that totals 12 bytes, at a 25 microsecond cycle (40 killohertz) that's only 480 kBps. 10 base T is fine there too. So I wrote down the spec and figured I'd probably use 10/100 because it's pretty common and some overhead couldn't hurt, considering it's cheap.

So up till that point in the first meeting I think their requirements make sense. But even before our first meeting was over they specified that they wanted Gigabit ethernet. I explained that it might not be needed, but ok.

My next meeting was to tell them about the controller and firmware architecture I had selected. I had chosen an SBrio-9637. It has the speed, it has 512 MB of memory, a 667 MHz processor, analog I/O that is fast enough and runs at 0-10V. At this point I was told they didn't want a PLC, wanted atleast 2 GB of ram, and that it should have two gigabit ethernet ports. Not for any new requirement, just do do what is outlined above. Also that they "don't want a whole other PLC" in the system. Particularly annoying is that while I put in my contract that changes to the requirements will require an adjustment in my price, it technically doesn't say that arbitrary changes to the specs cost extra. I don't desperately need the work, but they are paying me a lot and it is a bad idea for a contractor to blow off clients, even if they are being a bit unreasonable, (and a little condescending, but I won't go into that).

But back to the original point, I ordered an SBrio anyway. I figure what they want is something that does the job.

I hear your conccerns, I have been a contractor for a very long time, and yes it is easy at times to stick to the "Customer is always Right" and at the end of the day its their choice on how to proceed but I would in writing express you concerns that this "Directed" engineering may not work and while you will get behind it, you will not be held accountable if it does not pan out and that additional expendatures will be at their expence.

Basically your willing to help but if they take the descisions away from you then you can not be hed accountable, if they dont accept then I would walk.

Bow back to the task at hand. I would be concerned about a CPU scanning hundreds of meggs of data in under 25u Seconds, remember it has to do other things at the same time

Faster network ports will give faster bit rates but will not necessaraly give you faster data transfer overall at the end of the day, it is also not a feature worth arguing about.

I would consider the PID loops being handled by a seperate processor and being fed by the master ?

Based on the other parameters I would consider an FPGA to help out, I have never used one but plenty of folks here have, the timeing to get to collect data with only a 2mS event is pretty tight and I am assuming that there is a lot of work to do within that 2mS

I'll stick my neck out here and suggest that the huge array could be reduced in size with a bit of interpolation or curve fitting - this would be pre-processed and make the ROM requirement much smaller. (I know they think it should be in RAM but that's plain daft - a look up table is read only so could live in flash - possibly on an SD card but beware latency and stuff.)

The NI card looks OK (choking down my prejudice against NI here ) and if you are a LabView person it seems a reasonable choice - it's not  a PLC - just a single board computer with an FPGA .

Most of their requirements are plain silly - the dual ports, huge ram etc will push you to an "applications" type processor with a big OS (Linux, BSD, whatever) and you'll struggle to get the fast response.

If it were me I would offer a custom board based on an ARM Cortex M4 or M7, 10/100 Ethernet, not much RAM, lots of flash (some of the latest ARM Cortex processors can map serial flash into their memory space and most have built in NAND flash controllers).

If they insist on the silly stuff and you want to humor them, use an applications type SBC and an ARM Cortex, the ARM will do all the real work and the SBC will twinkle the lights and work the Ethernet ports. (Peter suggested much the same thing but less cynically.)

In the end you have to propose to your customer what you feel is the right solution - if they insist on doing it their way you may have to dig your heels in - usually I've found that with decent engineers this increases respect, where it doesn't just wave good bye. (Easy for me to say from here I know !)

MK