开云体育

?

I posted about this a few weeks ago (topic #199243). I even included a flow chart diagram of the particular system where I ran across the issue I was trying to solve initially. At the time I got little or no response from the group. Possibly it's not a situation many others have encountered.?

There are certainly multiple approaches to solving conflicting resource issues but in my case the solution ended up allowing three instances of the same compiled program to run on three different processors and all be able to use a different EISC IPIDS to talk to the correct program where it's necessary COM ports and DM devices were defined.?

The obvious way to accomplish this was to define multiple EISC symbols at multiple IDs and write the IP table from the program at runtime to only use the IPID needed, but I found that to be conceptually messy and could possibly cause issues with another program not being able to register an IPID, depending on program start order which I can't always control.?

In the end, I chose to use an empty program slot to define an EISC at an IPID consistent with the one in the compiled room program and another at the true destination IPID. Effectively "transposing" from one IPID to another. The only things in the program are two EISC symbols with however many joins necessary defined to simply pass signals straight through. I simply manually set the IP table as necessary. The room program passes it's signals to/from a ?transposition program in the same processor which then steers them to/from the correct destination (could be a program in the same processor or a different one).?

Another trick is to use S# libraries with static variables to pass data from one program to another without having to define any hardware symbols (like EISCs) with potentially conflicting IDs.

On Sep 23, 2014, at 9:53 PM, j pride jpride@... [Crestron] <Crestron@...> wrote:

?

"or (my personal new favorite approach) using an empty program slot as an IPID resource translator/relay, but in my experience it pays off in spades when I can use the exact same compiled code in multiple slots on the same or different processors”

Can you expound on the first concept in this quote? Also, how can one load the exact same code into multiple slots on the same processor if com ports and ipids can't be shared, unless each program isn't using those things (which seems unlikely)?

Sorry for the formatting, on my phone...

On Sep 23, 2014 1:44 PM, "Neil Dorin neildorin@... [Crestron]" <Crestron@...> wrote:

?

All of the resource sharing concerns/restrictions are quite well documented in online help and Crestron Labs.? It's not like it's a secret that programs can't share COM ports, IPIDs, Cresnet IDs, etc.

Sure it's sometimes a challenge that requires either re-writing the IP table from the program at runtime, or (my personal new favorite approach) using an empty program slot as an IPID resource translator/relay, but in my experience it pays off in spades when I can use the exact same compiled code in multiple slots on the same or different processors.? It makes for a far more consistent product, especially when dealing with large commercial projects with multiple rooms that function identically.

On Tue, Sep 23, 2014 at 12:28 PM, neil.carthy@... [Crestron] <Crestron@...> wrote:

?

Maybe obvious in hindsight but I wasted an hour or so debugging an ethernet device that wouldn't connect to a processor before I realised that I had used that particular ethernet slot on a different program. The error in the processor log file was unambiguous but I checked a lot of other things before getting to that.

Now, if I have multiple programs, I make sure that they do not use overlapping ENET slots.