Circumventing scratchpad bit limitations


#1

I need to configure 40 event messages to trigger under different situations on an EB2, but I don’t have 40 scratchpad bits available (event messages only trigger on scratchpad bits as far as I can tell).

Since the events are combinations of 2 properties, I figured I could reduce the number of SP bits to 14 (4 options for group # (A) and 10 options for # in the sequence (B)) or fewer by using multiple bits for the message trigger, but I need to make sure that there is no ambiguity (i.e. if bits 0 and 1 for A are enabled and bits 4 and 5 for B are enabled, it’s unclear which event(s) should be triggered - 0,4; 0,5; 1,4; or 1,5). For each independent A, B increases after some amount of time (variable). For example: 0,4 (30000ms)-> 0,5 (25000ms)-> 0,6 etc. and 1,4 (15000ms)-> 1,5 (30000ms)-> 1,6 etc.

The easiest (though not very elegant) way that I could see to do this would be to clear the bits after allowing time (1000ms?) for the appropriate event message to trigger. Subsequent bits could only be set when all the bits were clear, the event before them had triggered, and the appropriate amount of time had passed. The last two issues can be tracked using bits from a 64-bit integer, but I can’t check both a 64-bit integer and scratchpad bits since they’re both only available under trigger 2 (and reaction 2) due to this bug. At that point I was stuck, so I thought I’d see if anyone here had any ideas.

This is a ‘nice to have’ feature for my project, as opposed to a ‘critical’ one, so I’m just looking to make this work on an EB2 (if possible) rather than switching to a controller.

Thanks!


#2

Rather than bending your mind around those trigger bits, I’d strongly recommend you switch to a SNAP-PAC-R (or other PAC –- even SoftPAC may work, depending on your application, or possibly PAC Sim – which is FREE).

Then you could use the PAC Control commands like “Set I/O Unit Event Message State” for up to 128 messages per I/O unit. Of course, once you switch to a PAC your options for solving your bigger-picture problem also expand greatly. (Can you tell us more about where these messages go and what they’re for? If you switch to a PAC there might be a more elegant solution than using those Event Messages.)

The reasons for this recommendation are many; the biggest is for maintainability. Using a flow chart with a simple command is much clearer and easier the next person (or even yourself, tomorrow) to figure out what’s going on there. The cost of a controller is relatively small compared to your time and potential headaches. We developed those event-reactions before – and as something of a precursor to – the option to run a nice, easy-to-understand and maintain strategy right there on the rack.

Also consider future expansion where you might need more messages or other options. Much easier to make upgrades and changes to a strategy than sorting through these trigger bits. You don’t want to be getting phone calls from someone who inherits your system after you’ve moved on to bigger and better projects.

Is cost especially important here because you’re prototyping some sort of machine you’ll want to mass-produce?

Do share!

-OptoMary


#3

Hi Tricia,

Rather than bending your mind around those trigger bits, I’d strongly recommend you switch to a SNAP-PAC-R (or other PAC –- even SoftPAC may work, depending on your application, or possibly PAC Sim – which is FREE).

Then you could use the PAC Control commands like “Set I/O Unit Event Message State” for up to 128 messages per I/O unit. Of course, once you switch to a PAC your options for solving your bigger-picture problem also expand greatly. (Can you tell us more about where these messages go and what they’re for? If you switch to a PAC there might be a more elegant solution than using those Event Messages.)

The reasons for this recommendation are many; the biggest is for maintainability. Using a flow chart with a simple command is much clearer and easier the next person (or even yourself, tomorrow) to figure out what’s going on there. The cost of a controller is relatively small compared to your time and potential headaches. We developed those event-reactions before – and as something of a precursor to – the option to run a nice, easy-to-understand and maintain strategy right there on the rack.

Also consider future expansion where you might need more messages or other options. Much easier to make upgrades and changes to a strategy than sorting through these trigger bits. You don’t want to be getting phone calls from someone who inherits your system after you’ve moved on to bigger and better projects.

Is cost especially important here because you’re prototyping some sort of machine you’ll want to mass-produce?

Do share!

-OptoMary


#4

hi tricia
i have played around with the scratchpad stuff a bit to get some low level control on an eb2 as well, even to the point that i ‘broke’ it (i had something like 100+ digital events sequencing some digital I/O and it would lock up after a while. after contacting support they advised that the digital events weren’t designed to handle that much load and i eventually switched to a R2. to opto’s defense it was firmware version 8.1 or 8.2. maybe things have changed internally that eliminated this limitation with newer firmware versions). the idea was to have the brain work autonomously of the central controller in case communications were compromised.

the scratchpad bits you are using to trigger your event messages are a hex value. so therefore you have a total of 64 single bits you can use to trigger your events. a hex value of 0x0000 will give a total of 16 ‘bits’ to toggle. example: 0x0001 will equate to 0000 0000 0000 0001 binary. 0x0002 will evaluate to 0000 0000 0000 0010 binary. 0x0004 will equate to 0000 0000 0000 0100 and so on… so a hex value of 0x00000000 00000000 will give a total of 64 single bits that can be used to trigger your events. then any other combination of this can expand it out to whatever your heart desires (until it becomes a jumbled mess…) a single bit doesn’t have to be used, you can use values like 0x0003 which would mean bits 0 and 1 would be set to trigger your event. it can get quite large and complex when you start delving into it.

you say the events are a combination of 2 properties, what sort of properties?? if all digital then you should be able to get something sorted pretty easily with just getting your combinations correct to trigger the scratchpad bit. if you are using a combination of alarms and digital then, yes you are kind of limited to 32 bits in as one bit will be used to convey the status of the alarm and the digital will be used in conjunction with the set scratchpad bit to confirm the event, simply speaking.

mary is right though. the amount of time to configure the events and ensure they work correctly and there are no bugs would greatly outweigh the cost of buying an R2 and just writing a strategy to handle your logic. if its a personal project then i can understand that it may not be viable to purchase a controller and you would like to pursue the E/R path.

i’m a bit of a fan of the brain E/R stuff, but it does have its limitations…can you give some examples/screenshots of what you are doing?

Nick


#5

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


#6

Wow, I think you’ve set the new record for longest forum post. :slight_smile:

I’ve had an extra cup of coffee, and hopefully I’m comprehending most of what you’re saying here. Let me recap to make sure.

Pushing the logic down into the EBs is important because:

  1. Cost IS a factor here
  2. You’re leveraging the built-in intelligence of our modular/distributed I/O brains (I get that and love that you do too!)
  3. The E/R stuff is kind of fun. Hate to admit that I kinda get that too.
BTW, you mentioned communication delays so I wanted to make sure you’re aware if this [System Performance Technical Note, form 1776](http://www.opto22.com/site/documents/doc_drilldown.aspx?aid=3965).

I’m not entirely confident I get the rest of what you’re saying here, but I’m always game for a good brainstorm, especially when it comes to creative ways to approach a particular challenge.

I think you’re telling us:

Your main goal here is to move some setpoints (possibly 10 options for each of 4 chambers/PID loops) depending on various inputs in the system. But you’re running out of trigger SP bits and are concerned about potential overlap between trigger bits. Did I get that right?

So here’s a wacky idea that could help you circumvent the SP bit limitations, which is where you started this topic (forgive me if I’ve misunderstood or made some invalid assumptions here).

Let’s use an example, to increase the odds of this making sense. Say for a particular situation, you want to copy a particular setpoint SP float [0] and its current value is 22.22 (that’s address F0D82000 and the data in hex is 41B1C28F).

Right now I think you have an event message that copies from that SP float[0] address to the appropriate PID setpoint based on certain digital events that changed trigger SP bits, yes?

Could you instead configure 4 event messages (one for each chamber/loop) which each copy a value from SP int64[X]? For example, the first event message could copy data from SP int64[0] which just happens to have 41B1C28F stored in it? (Aka your 22.22 value or whatever you currently have in SP float[0].)

How to get those bytes into SP int64[0]? Your digital event reaction just needs to have the appropriate ON/OFF mask in reaction 2 going to SP 64[0]. In this example, ON mask: 41B1C28F and OFF mask is the bitnot of that: BE4E3D70.

What I’m trying to take advantage of here is that:

  1. You have loads (1024) of SP Int 64 values available, which you can write directly to using a digital event.
  2. Your Event Message which moves a particular setpoint value to your PID loop doesn’t know/care about data types, it’s just moving 4 bytes of data from address X to address Y. So address X may as well be a location in that massive SP Int64 array, which just happens to hold 22.22 (or your set float value here).
I hope that made sense!

-OptoMary


#7

Thanks Mary!

Your understanding of the EB2 logic situation is correct :slight_smile:

As for the performance note, we do indeed know of its existence now, but our software’s original developers did not (it may not even have been published then…I’m not sure). It would be a major overhaul to ‘retrofit’ the old software (and it works reasonably well in its current state), so we’re just keeping that version and starting over with new software for our new hardware (keeping in mind the performance notes this time!).

Back to EB2s…I think you do understand the challenge correctly; your solution is very creative (I don’t think I would’ve come up with that anytime soon)! My grasp is still tenuous, but your idea seems to solve the problem. It’ll probably take me a little while to implement, but I’ll make sure to let you know how it goes.

Tricia


#8

Yay! I’m glad that made sense, at least a little.

FYI, here’s a trick perhaps you already know for getting a “float” as 4 hex byes. (For example, if/when you’re moving your setpoint values from the SP float area into the your SP int64 option in digital event-reaction “data for reaction #2.”)

In PAC Manager’s, Tools > Inspect > Other > Generic Read/Write page, you can access any mem map location and select which type to use to display those bytes of data. So here I’m looking at the address of the SP float[0] as a float (22.22), but then I changed it to Hex when composing my creative/wacky suggestion above.


Fun stuff!

-OptoMary


#9

So, just by way of update in case anyone else is reading this thread…I implemented a version of Mary’s suggestion (I needed OPC communication too, so I had to add a couple of definitions to make it work). It seemed to behave as expected, but it was painfully slow (as forseen by Nick). A good learning experience, but I think we’ll have to upgrade the hardware for any customers requiring this particular feature.


#10

Thanks for the update. Sorry to hear it was too slow.

FYI, looks like there’s a fix in the works for that issue where the “Expanded Event Reaction Fails If First Trigger Uses Scratch Pad Bits.” Would that help? I could probably get you a beta…


#11

Hey Mary, sorry for the delay…if there is a resolution to that issue it might help address this challenge (obviously I can’t be sure without trying it) and clean up some of the other ‘code’ that I wrote to get around that limitation. Thanks!