Nick and Mary,
Thanks for your replies!
Mary, to answer your main question about why an EB2 instead of a controller, it’s partly cost and partly modularity. We are prototyping for a new ‘mass’- produced product; we don’t produce things in huge quantities, but enough for the controller cost to matter (and the goal for this particular product is to keep the price down). The modularity goal is related to what Nick said as far as reliability…we’ve been running several EB2s with one controller and we’ve had some communication delays when we get up toward 10 EB2s. This is partially a design issue on our end with software (and particularly with the OPC communication design), so we’re improving it in the new version and trying to keep control/communication as modular as possible to prevent communication problems from interfering with control. The other issue is that our products are designed to be modular themselves, so it’s to our advantage not to have to write a new strategy if we expand the size limits/capabilities of the machine later (particularly for regulatory evaluation).
We are considering making this feature an extra-cost option to cover the cost of the upgrade from an EB2 to an R2 for each affected module so that we can run a strategy and maintain modularity, but it would be nice not to have variations on the hardware if we can avoid it (for manufacturing purposes).
I’ve already configured most of the required PIDs/alarms/events/event messages (which is why I’m running low on bit flags), but, basically, what I’m trying to do is run (potentially different) control profiles in 4 different chambers. At its most basic, this would involve transferring a scratch pad float to the appropriate PID setpoint after a set amount of time (I’m okay with this aspect of the problem; I’m already doing similar things). The issue comes with how to trigger the appropriate event message to do the memmap transfer.
As Nick said, I can use combinations of bits to trigger the messages, so, assuming ten setpoint floats per four chambers, using 14 bits is the most straightforward (I could actually make it as low as nine, but it gets even more confusing). Using this technique, however, I have to make sure that two chamber number flags and two setpoint number flags aren’t activated at the same time or four messages (rather than the intended two) would be triggered, messing up the profile.
The easiest way I could think of to prevent potential overlap is to only allow bits to be triggered if no bits are currently triggered. A more in-depth example (this refers to actual bit numbers, not the hex values, since it’s easier to read that way):
Event 1: when SP bits 4-13 are unset and SP bit 0 is set, set bit 4
Event 2: when SP bits 0 and 4 are set, wait 1000ms, then unset them
Event message 1: when SP bits 0 and 4 are set, transfer SP float 0 to PID 0 setpoint address
This is where the issue arises…how to trigger the next segment without using more bits?
First option: use another timer
Event 3: when SP bits 0 and 4 are set, wait for the profile setment length (30000 ms, for example) then set bits 0 and 5
Event 4: when SP bits 0 and 5 are set, wait 1000ms, then unset them
Event message 2: when SP bits 0 and 5 are set, transfer SP float 1 to PID 0 setpoint address
the problem here is that there’s a possibility that two sets of bits get set at the same time (for two different chambers, since they’re independent). I’m pretty sure that there’s no way check that the bits are empty after the timer expires but before the new bits are written.
Next option: use SP Integer 64 bits (this just assumes integer 0)
Event 3: when SP bits 0 and 4 are set, wait for the profile segment length (30000 ms, for example), then set SPI64 bit 0
Event 4: when SP bits 4-13 are unset and SPI64 bit 0 is set, set SP bits 0 and 5
Event 5: when SP bits 0 and 5 are set, wait 1000ms, then unset them
Event message 2: when SP bits 0 and 5 are set, transfer SP float 1 to PID 0 setpoint address
In this case, the problem is with Event 4: there’s no way to check the SP bits and the SPI64 bits in the same event.
Third option: use another SP integer 64 bit to indicate SP bits are clear
Event 3: when SP bits 0 and 4 are set, wait for the profile segment length (30000 ms, for example), then set SPI64 bit 0
Event 4: when SP bits 4-13 are unset, set SPI64 bit 32
Event 5: when SP bit 4 is set, unset SPI64 bit 32
Event 6: when SP bit 5 is set, unset SPI64 bit 32
Events 7-14: etc.
Event 15: when SPI64 bits 0 and 32 are set, set SP bits 0 and 5
Event 16: when SP bits 0 and 5 are set, wait 1000ms, then unset them
Event message 2: when SP bits 0 and 5 are set, transfer SP float 1 to PID 0 setpoint address
This might work, or it might not…Assuming that the all of the event conditions are checked in order, if SPI64 bit 0 (signalling chamber 1, setpoint 2) and SPI64 bit 10 (signalling chamber 2, setpoint 2) were both set for a single scan, then SPI64 bit 32 would be set for the events checking both of them (it wouldn’t have a chance to reset between the two events). The scanning is fast enough that this probability is probably small, but I’m not sure it’s small enough.
Sorry this is so long, but hopefully it gives you a better idea of what I’m trying to do. I’m not sure there is a way around switching to the controller, but I kinda like the lower-level control - it has some advantages for us and it’s an interesting challenge, anyway. Thanks!
Tricia
