G4eb2

I assume that with a name like “EB2” the new G4EB2 boards are essentially an EB2. Also, since it is an EB2 it does not have a counter chip so it cannot high speed count. Can I assume that the lack of a counter chip has nothing to do with the scan rate that the brain scans the rack or do the EB1’s scan at a faster rate, or does the counter chip make seperate scans from the brain cpu? Also, are the event reactions of the G4EB2 as fast as an EB1?

If the G4EB2 cannot handle the higher speeds of machine automation, can I get enough speed from an R1 used as a brain to emulate an existing pamux system controlled by a 486 with assembly code?

I made some assumptions about speed and I think the application moves material (sheet steel) through guides at about 16 ft/sec which means that a 1 inch movement is about 5ms. At this speed, I would probably need at least better than 25ms input to output reaction times.

Most of the movement is controlled by a 14.5 hp servo drive, but some of the movement is controled by photo eyes.

Hi Barrett,

There are few questions in here, so lets take them in the order you have them and see if we can straighten them out.

Right. The G4EB2 does not have the EB1 counting chip, so it cant do any on brain counting.
Right. The lack of the counting chip does not change the brain scan rate. In the case of the EB1 think of the digital input modules going directly into the counting chip, so the counting function has nothing to do with the scan speed or TCP/IP load on the brain. Regardless, the [I]scan speed[/I] for the event reactions etc will be the same for an EB2 as an EB1. Its just that at any stage your strategy can ask for the count and will get an accurate number from an EB1.

Cant say about ‘emulating’ a pamux system with an R1… That’s a loaded question. Pamux is really fast. Is the 486 running anything other than DOS? How busy is the network? Remember, every single TCP/IP packet on the network is going to demand CPU cycles from the controller / brain CPU to check it for its MAC address. Thats why we put the ‘0xFFFF F038 0294 | Digital Feature Scan Interval (msec) | 1’ setting in. It used to be possible to ‘swamp’ the TCP/IP stack and since that has a higher priority than the digital or analog scanner, the controller/brain would not poll the point data often enough and you could end up with stale data… So, perhaps now you can see why we cant straight up answer your question on this one… Pamux did not have things like TCP/IP to deal with.

Cheap, fast, powerful. Pick any two.

Some good questions that got into the nitty gritty of the controller / brain there Barrett. Sure sounds like an interesting application.
Edge case applications are the most risky, and the most rewarding.

Ben.

As I mentioned, in the other post I don’t actually have the job but thought the topic was good for all. The idea here would be to replace the 486 which is a black box as well as the fact they had a couple of hickups and realized it could shut down production for weeks if it fails since 486’s are hard to come by. Since the PC was going to be removed, the only other reasonable alternative is to use an S1 and the G4EB2’s. This eliminates the overwhelmnig bulk of wiring work (6 x 32 points) and I could jus add an R1 (to use as a brain and do any high speed counting required as well as analog. The existing IO except for counting should be fast enough for most operations and the R1 can handle anything that needs to be really fast. My thinking is that if I have to I could use an R1 for any analog and another to handle any discreet counting/really fast discreets by turning off the analog scanner and HD scanner in one and the digital and HD scanner in the other. The cost of an extra R1 or two is not a consideration. Currently the 486 has an analog input card on it and also has an encoder input on it and I guess tells the servo drive the final location or something like that. I would replace the servo drive with something newer (currently EOL) and do the entire postioning in the servo drive, then have an output from the servo drive for final position so the opto system can operate the shear after looking at all permissives. The S1 could then go to the servo and get the positional data for QA via serial.