R1 and S1

Other Opto Products
1

Let’s say that I have an application that requires high speed reactions to a process. Therefore I would be looking to find the highest speed means of building an Opto22 control system. When using the R1 as a brain, and by using the R1 to send and receive scatch pad data to an from an S1, woulld this be the highest speed means of getting data into and out of an S1? OR would just polling the R1 be faster?

Also, will the new Pac Control in a PC be able to outstrip the speed of the exisitng I/O hardware platform? What kinds of speeds could I expect from an R1 as brain from such a system?

2

I’m not sure I completely understand what you’re asking here, but let me suggest a few things that might be relevant.

In general, we tend not to get specific about overall “speed” because there are just so many variables involved, including network traffic and which I/O modules you have plugged into a rack – just to name two.
When you say: “high speed reactions to a process” the first thing that pops in my head are the Event/Reactions one OptoFan raves about in this post.

Also, as Ben mentioned in this post, if you can have all your logic on that same R1, that’s the most efficient and takes the most advantage of “distributed I/O.” After you’ve done the high-speed process stuff, then you might report back to a master S1 about how many widgets were built or whatever.

Another thing folks overlook sometimes is the speed of the module itself. There’s no point in grabbing information from a module faster than the module itself can update. Check your specific modules specs for numbers like these:

Also, depending on what you’re doing on your R1, there are options in the memory map to turn off your analog scanner, digital scanner, and even the control engine (or any combination). Search for “scanner flags” in form 1465. Turning off what you’re not using can free a few more CPU cycles up for what you are using.

I think you’re asking about SoftPAC too, which is primarily going to help folks who’d like faster speeds for the logic itself (especially math and string processing), more charts, and more room for storing data in memory and in files. Since it’s running under Windows, when you communicate with another PAC like an R1 or S1, it’ll be through the Windows TCP/IP stack which has, well, limitations. Don’t get me going on that topic!!

There are a couple other considerations when you’re trying to eek out faster performance, but I think that’s a good start for now. Do you want to give us more details about what you’re trying to speed up, exactly?

Thanks,
-OptoMary

3

I’m not sure I completely understand what you’re asking here, but let me suggest a few things that might be relevant.

In general, we tend not to get specific about overall “speed” because there are just so many variables involved, including network traffic and which I/O modules you have plugged into a rack – just to name two.
When you say: “high speed reactions to a process” the first thing that pops in my head are the Event/Reactions one OptoFan raves about in this post.

Also, as Ben mentioned in this post, if you can have all your logic on that same R1, that’s the most efficient and takes the most advantage of “distributed I/O.” After you’ve done the high-speed process stuff, then you might report back to a master S1 about how many widgets were built or whatever.

Another thing folks overlook sometimes is the speed of the module itself. There’s no point in grabbing information from a module faster than the module itself can update. Check your specific modules specs for numbers like these:

Also, depending on what you’re doing on your R1, there are options in the memory map to turn off your analog scanner, digital scanner, and even the control engine (or any combination). Search for “scanner flags” in form 1465. Turning off what you’re not using can free a few more CPU cycles up for what you are using.

I think you’re asking about SoftPAC too, which is primarily going to help folks who’d like faster speeds for the logic itself (especially math and string processing), more charts, and more room for storing data in memory and in files. Since it’s running under Windows, when you communicate with another PAC like an R1 or S1, it’ll be through the Windows TCP/IP stack which has, well, limitations. Don’t get me going on that topic!!

There are a couple other considerations when you’re trying to eek out faster performance, but I think that’s a good start for now. Do you want to give us more details about what you’re trying to speed up, exactly?

Thanks,
-OptoMary

4

I always look at the I/O speeds if speed is a concern, I know not everyone bothers. Let’s talk about the analog, if you neet to do calcs based on an analog input and you need a fast turn-around, the analog IO in the 2 channel is the fastest at 11 ms. Now that doesn’t take into account the brain scan rate, the controller poll rate, the logic decision time, the next controller poll time, the next brain scan time, and then finally the output reaction. If the output reaction is analog, then that’s another 3msm, the DC digital outputs are fast at 100microsecs. Now let’s look at the digital side, most machine control actions are digital and the speed of the Opto dc digital are quite fast (and I could have sworn the last time I reviewed the dc digital output specs they were around 5-10 ms.). Therefore the speed is primarily limited to the brain scan rate if it is assumed the control is in E/R. My experience in watching brain scanner rates is that typical scan times are around 5-20 ms.

Does the E/R require 2 scans to produce a reaction, or does it happen in 1?

If it is necessary to use a timer in E/R, then the timer resolution is the time value + the scan rate.

Thanks for the tip on the scanner flags, had no clue they existed. I suppose that’s Bryce meant when he told me years ago that the R1 makes a really fast brain. I am really curious now regarding just how fast the R1 as brain can provide an E/R when the analog and the high density features are turned off.

I was impressed by what Ben said in his post on the PID loops, had no idea the PIDs would work that good at 10ms on an R1 running a strategy.

The app I have just quoted has transformer lamination sheets being accelerated to about 10 meters/sec, stopped to be sheared at +/- 0.004" accuracy and then re-accelerated off the line. My guess is the machine is at least 30 feet long and the sheets are being produced at 60 per minute.

Now here’s a thought. What about 2 port ethernet PC buss card that uses one port for Xmit and one for recieve and talks to a “Pac Pamux” brain. The buss card has drivers for Linux and talks to the new Linux ported Soft Pac.

5

Just to be sure we’re on the same page, when you’re talking about “watching… scan times” are you doing this in PAC Control’s debug mode, by inspecting the I/O unit then clicking on the “information” tab? (As shown below, before I turned off the control engine on that R1 then after.)

Of course, as mentioned earlier your mileage my vary widely depending on what’s happening with the rest of your system, but I just wanted to make sure talking about the same numbers here…

6

No I was referring to Pac Manager inspect mode but this is the same data apparently. BTW, I don’t ever remember seeing scan rates that low. Maybe that’s becuase I am usually looking at an EB2?
So therefore are you suggesting that if I were to be using an R1 as brain with the other scanners turned off, I would be getting scan rates of less than 1 ms? If that’s the case then there’s no problem, I should be ok with that arrangement.

7

Hi Barrett,

I’m going to jump in here and say the same thing I said in our other thread.
No, you are not always going to get scan rates of less than 1ms with the control engine turned off. The reason for the uncertainty is that pesky TCP/IP stack. The more you poll the controller / brain, the slower the scan rate.
Its one of the best catch 22 situations around. You want a fast system, you need to update fast, so you poll it fast, the faster you poll it, the slower it goes.
There will be a sweet spot for sure. Is that spot less than 1ms. Depends.
Also, don’t forget that even though there are two Ethernet ports on the controllers, there is only one CPU, so if you try and have one high speed (quiet) network and the other is on the office network, your scan rates will still go down as every email/print/YouTube packet is looked at by the controller CPU and analyzed to see if its addressed to it.

For everyone reading along, keep in mind that these sorts of speeds/tweaks are not normally an issue. We are talking about a really cool edge case here, not your usual process or automation use case.

Ben.

8

Ok, so in this case, I could use a router to provide only routed packets to the R1 “brain” apart from the packets to and from the MMI and the S1 (acting as the actual controller here). Or as you suggested, use the second Ethernet port on the S1 to keep all the traffic dedicated to IO traffic which in itself will keep any miscellaneous packet traffic off the brains ports. Yes the S1 would still have the MMI tcp traffic but the other port would only have udp traffic to and from the brains.

I could further limit incoming packets to the R1 “brain” by using E/R notifications in the S1 and the only comms from the S1 would be necessary reaction or management actions to the R1 “brain”. I.E; exception based comms from either side, or comm updates based on lower activities in the strategy…I can see where it could be pretty fast.