开云体育

?

You don't need the file names anymore, and drop the -P:1 for panels.? That is the program slot designation for a 3-series processor.

?

I still load that way....only reason is, i have NO CLUE how to load with an ftp.? any help there would be greatly appreciated.? Thanks.

?

Neil, thank you for typing that up. I bookmarked it and will check that out next when i start messing with multiple apps per processor.?

::::::::::::

J Pride

On Wed, Sep 24, 2014 at 1:53 AM, Neil Dorin neildorin@... [Crestron] <Crestron@...> wrote:

?

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.

?

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.

?

Hi there,

does anybody have some experience with converting relative humidity to absolute humidity, using SIMPL+ and is willing to share?

In the project at hand, a ventilation system is supposed to bring down humidity in an underground cellar. Since warm air can hold more water, blowing warm air into the cool cellar might actually lead to water in the warm air to condense in the cool cellar. Therefore the absolute humidity in grams per cubic meter has to be taken into account. Only if the absolute humidity outside is below the absolute humidity inside the fan should blow fresh air into the cellar.

So far, I have installed two C2N-RTHS, one inside the cellar and one outside. So temperature and relative humidity are available.

I also found a formula for MS-Excel that works fine there. But I have trouble to implement the f! ormula in SIMPL+, as there is no "power of x" operator of function available.

The Excel formula looks like this:

aH = 13.233 * rH * ((10 ^ ((7.5 * T) / (237 + T))) / (273.16 + T))

where aH is the absolute humidity, rH the relative humidity and T is the temperature in degrees Celsius.

Does anybody have a module that does the conversion or can hint how to do the conversion in a Crestron system in general or how to implement the formula above in SIMPL+?

Any help is appreciated!

Thanks!

Markus