Way to prevent duplicate components?

[BobWirka]

First, thanks to all who have replied to previous posts.

Now, is there a way to prevent placement of duplicate components on a wire sheet?

We'd like to present a selection of components, each of which should only be placed once as each corresponds to a fixed i/o resource.

Thanks,

Bob Wirka

[McKenney, Elizabeth (Tridium)]

I don't think there's any way to prevent it via the wiresheet or palette.  But you could do it in your Sedona code.

 

For example:  You could create a Service subclass, and have each of your IO components register with that service in their start() methods.   The service's registration method would return a value telling the component whether or not it was a duplicate, and if it was then the component would disable itself and not run. 

 

 

---

From: sedo...@googlegroups.com [mailto:sedo...@googlegroups.com] On Behalf Of BobWirka
Sent: Wednesday, February 08, 2012 9:49 AM
To: sedo...@googlegroups.com
Subject: Way to prevent duplicate components?

--
You received this message because you are subscribed to the Google Groups "Sedona Framework" group.
To view this discussion on the web visit https://groups.google.com/d/msg/sedonadev/-/1pCdnS9IgGUJ.
To post to this group, send email to sedo...@googlegroups.com.
To unsubscribe from this group, send email to sedonadev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sedonadev?hl=en.

[Bob Wirka]

Elizabeth,

Thank you for your reply.

After a component figures out that it's a duplicate (in start()), what should it do to prevent itself from being placed on the wire sheet?

Thanks,

Bob Wirka

[McKenney, Elizabeth (Tridium)]

There's no way to prevent it from being placed on the wire sheet, once the user has put it there (that I know of).

But the component could prevent itself from executing any code that touched the hardware.  It's not a complete

solution, I realize. 

---

From: sedo...@googlegroups.com [mailto:sedo...@googlegroups.com] On Behalf Of Bob Wirka

Sent: Wednesday, February 08, 2012 11:28 AM
To: sedo...@googlegroups.com
Cc: Bennet Levine
Subject: Re: Way to prevent duplicate components?

[Bob Wirka]

Elizabeth,

Would you be kind enough to point me to an example of a "Service subclass"? Is there anything special about such a class?
--or--
Is this any different than declaring a class with a static function that can be called by the components? Said class would have static variables that would keep track of instance usage.

Also important: can a component tell when it's been removed from the wire sheet? Let's say a user puts down a component, then removes it, then puts it down again; our service function will get confused if the removed component can't log the removal event...

It looks like each component has an integer ID and an id() method to get it. When a component is removed from the wire sheet, is there a Sedona component or an event in the vm that I could hook to see which component is being removed? If need be, we could keep track of used instances on the target, but we'd need to know when a component was removed.

Thanks,

Bob

[Bob Wirka]

Follow-up question: Native functions have the format:

Cell NativeFunction(SedonaVM* vm, Cell* params)

where params[] hold the passed parameters. Is there anything in the 'vm' parameter (in the SedonaVM structure) that might uniquely identify the calling component?

Thanks,

Bob

[McKenney, Elizabeth (Tridium)]

You have a good point, a class with a static function would work just fine. 

 

A Sedona component has no concept of a "wire sheet", per se.  The component is on your remote Sedona device, whereas the wiresheet is simply a local snapshot of what is happening on the remote device.  When you make a change in the wiresheet, Workbench sends a Sox message to the device telling it to add/remove/modify that component on the remote device to match what you just did in the wiresheet.

 

So the real question is, what part of the software running on the remote Sedona device is aware when a component is deleted from the app?  The device's SoxService receives the delete command from Workbench, and makes a call to App.remove() to delete the component.  Looking at the source for App.remove(), it appears that if the app is running (which is usually the case when you are editing a live app in the wiresheet) it will call the component's stop() method before deleting it.  (In my copy of App.sedona this is line 459.)

 

This means that you should be able to override your component's stop() method to do whatever is needed when a device is deleted from the wiresheet. 

 

(Hope you don't mind the long-winded ramble, but I thought you might find it helpful to see where I got your answers from.)

 

 

For future reference, there are two useful things about any subclass of Service:  (1) it has a "work()" function that may get called multiple times per App cycle.  This is sometimes useful, but you are correct that for this particular purpose that feature is unnecessary.  (2) it can be looked up by type via the App.lookupService() method.  This is helpful if you want to access, say, the SoxService in the app.  Normal components can only be looked up by component id, which is no good if you don't know the id in advance.

 

---

From: sedo...@googlegroups.com [mailto:sedo...@googlegroups.com] On Behalf Of Bob Wirka

Sent: Wednesday, February 08, 2012 4:06 PM

[Bob Wirka]

Thank you, it looks like the stop() function will do the trick.

Another issue: How can I prevent a class that extends a component from showing up in the workbench?

I've got a base class that extends a component and has all the needed functionality for that type of component. Then, we extend that base class multiple times to implement each individual I/O point on the device:

// Don't want this class to show up in workbench
class Base_IO extends Component
{
    code/data generic to an I/O group.
}

// Want this class to show up in workbench
class Individual_IO extends Base_IO
{
    code/data specific to a particular I/O point within the base group.
}

Both classes show up. Is there a way to limit the classes that appear in workbench? If we have to use multiple instances of the base class, there will be a lot of redundant code...

Thanks,

Bob

[Bob Wirka]

PS: The explanation was great. Don't worry about being long winded.

Thanks again,

Bob Wirka

[argeden]

Hi,

We had similar problem on our modbus kit. We want to be sure about
hierarchy of components related to the modbus. For example, the modbus
device must be under the modbus network and the modbus point must be
under the modbus device and like so. So we need to remove the
component if it is placed against the hierarchy. There is no mechanism
in the workbench to solve it. So we have to solve it dynamically in
the sedona code. Let me try to describe you our solution. We added
some code to start() method of the component. It checks if it's
parent's type is suitable or not. If not, it writes a value to a
register to show there is a problem about the placement. Then, when
execute() method of the component worked, it checks the register and
if it says there is a problem about the placement, the component
removes itself. The command is "Sys.app.remove(this)". So, if there is
a placement problem, the component removes itself from the
application, you cannot put it to unsuitable place.

You may use similar technique in your code. You must check if there is
same component placed before in start() method. If yes, remove it in
the first execution. The problem is, you have to scan all the
component list if there a duplicate one. This may take too much time.

I wish this may be helpful,
regards

[Matthew]

Can you just make Base_IO abstract?

abstract class Base_IO extends Component ...

Abstract classes will not show up in the palette in workbench.

[BobWirka]

Matthew,

This sounds exactly like what's needed. Am coding it now.

Another question: If an array of integers is delcared as "static inline int[10]    comp;", will they all be initialized to '0'?

Thanks,

Bob Wirka

[Matthew]

It depends. If your svm uses the open source implementation of sys_Sys_malloc (see src/sys/native/sys_Sys.c) then yes because the default implementation zeros out all memory when it is allocated.

If sys_Sys_malloc has a custom implementation for the target platform, then it depends on that implementation.

[Bob Wirka]

Matthew,

Thanks.

Yes, the memset() is there.

Bob Wirka

On Fri, Feb 10, 2012 at 10:06 AM, Matthew <matthew...@gmail.com> wrote:

It depends. If your svm uses the open source implementation of sys_Sys_malloc (see src/sys/native/sys_Sys.c) then yes because the default implementation zeros out all memory when it is allocated.

If sys_Sys_malloc has a custom implementation for the target platform, then it depends on that implementation.

--
You received this message because you are subscribed to the Google Groups "Sedona Framework" group.

To view this discussion on the web visit https://groups.google.com/d/msg/sedonadev/-/5loR3FiCa5IJ.

[senthil]

hi

one room inside two numbers equipment example ( fcu )  i want change over 1 week 1fcu run how to do the schedule or programming ?