开云体育

I thought this sounded like a fun exercise, so I worked something up using Robbie's method mentioned above.

I broke it down into x and y coordinates for each button, tracking the value with analog signals. Pressing right/left will increment/decrement the x coordinate, and pressing down/up will increment/decrement the y coordinate. Using the Numeric Keypad symbol allows the analogs to wrap around in either direction.

Then, I took the x,y coordinates and converted them back to digitals for feedback of the grid of buttons on the panel using a pair of EQUs feeding into 3 buffers.

This is scalable to practically any uniform grid size consisting of x columns and y rows.

Here's a link to a .smw file along with a screen shot of the logic flow.





--- In Crestron@..., "rlf79cm" <rlf79cm@> wrote:

That sounds great! A little beyond my Simpl abilities at the moment but I'm going to start trawling through the Help files straight away!

Cheers


--- In Crestron@..., Davis Whitehurst <whitehurstd@> wrote:

How about an analog inc for left/right that increments by 1 and analog inc for up/down that increments by 3. Run them into a sum. Add conditional logic for a wrap around effect. Obviously there would be a lot of buffers, ors and nors, but I think it could be done.

If value = 1.
Left sets it 9 for full wrap, or 3 if you just want to horizontal wrap
Right goes to increment
Down goes to increment
Up sets it 9 for full wrap, or 7 if you just want to vertical wrap
If value = 2.
Left goes to inrement
Right goes to increment
Down goes to increment
Up sets it 9 for full wrap, or 8 if you just want to vertical wrap

ETC...


Davis


________________________________

CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately destroy the original transmission and its attachments without reading them or saving them to disk. Thank you.


[Non-text portions of this message have been removed]

That sounds great! A little beyond my Simpl abilities at the moment but I'm going to start trawling through the Help files straight away!

Cheers


--- In Crestron@..., Davis Whitehurst <whitehurstd@> wrote:

How about an analog inc for left/right that increments by 1 and analog inc for up/down that increments by 3. Run them into a sum. Add conditional logic for a wrap around effect. Obviously there would be a lot of buffers, ors and nors, but I think it could be done.

If value = 1.
Left sets it 9 for full wrap, or 3 if you just want to horizontal wrap
Right goes to increment
Down goes to increment
Up sets it 9 for full wrap, or 7 if you just want to vertical wrap
If value = 2.
Left goes to inrement
Right goes to increment
Down goes to increment
Up sets it 9 for full wrap, or 8 if you just want to vertical wrap

ETC...


Davis


________________________________

CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately destroy the original transmission and its attachments without reading them or saving them to disk. Thank you.


[Non-text portions of this message have been removed]

I've got a system with 4 zones of garden lighting which are controlled via Crestron primarily on Mobile & Mobile Pro G.

However, we need to fit a wall station of some description in a location where cabling is impossible to control them as well.

Something like a cameo keypad would be ideal, but they all need cabling of one sort or another (I know there's a battery powered infinet keypad on the cards, but it's not been released yet to my knowledge)

There is a Pro2 nearby, so I'm thinking of a battery powered wireless solution somehow connected to the versiport inputs of the Pro2 and go programatically from there.

Has anyone got any idea of any elegant hardware I could use?

Cheers.
Mark

You could treat it like a 2D table.

Use AINC symbols with min/max parameters set to the size of your item grid. One for Up/Down and one for Left/Right.

Then use EQU symbols and ANDs to get digital FB of which one is currently selected.

You could easily wrap this in a module with parameters for the number of horizontal and vertical icons.

-Neil Dorin

Sent from my iPhone

On 2013-03-21, at 3:16 PM, "jrw_96" <jrw_96@...> wrote:

Off the top of my head you could use a ring counter to cycle through the icons and use the analog mode joins to show which icon is selected. The rest would be pretty easy logic wise.

JRW

--- In Crestron@..., "rlf79cm" <rlf79cm@> wrote:

I have a touchpanel menu with 9 icons - 3 rows of 3. I'd like to use the up/down/left/right buttons on the panel to scroll/navigate through the icons, with 'ok' selecting the desired item.

Obviously I can use up/down to control things like volume/channels etc, but I'm unsure how to use them to scroll through items/icons on the actual touchpanel - any ideas?

(Hope that makes sense)

Thank you!

Hi Matt,

That looks like a classic candidate for a state machine.

I.e. rather that attempt to parse a complete message in one mouthful, implement a routine that eats numbers, delimited by white space or the lf/cr.

Lf/cr resets the state machine and spits out your interesting data, and for each "number" you maintain a couple of state variables (data chunk, sub element).

And Atoi won't work on negative numbers will it?

Sorry this is a bit brief/vague, but I hate typing on my phone :)
All the best,
Ol

--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@> wrote:

Yeah, right, the string is not always the same, like I said, the attenuation value can be from 1 to 4 bytes long, for each channel. I was thinking of getting the LEN of the attenuation data, then MID the string based on that but seems more work than the removes anyway.

--- In Crestron@..., "jrw_96" <jrw_96@> wrote:

Use a buffer and collect everything in said buffer. Then just break it down as necessary. Only if the incoming strings are predictable and/or the end of the string is always &#92;x0d&#92;x0a...

If the above is true then this should be gravy for you. It's when you do NOT have set points (delimiter(s) and actual sub-headers differentiating the substring/channel info) [always seems to be my case with crc's and what not] that you have to wonder "is this really worth it" imo...

JRW

--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@> wrote:

Here's the string

0 0 0 0 1 0 0 0 0 0 0 0 -44 0 0 0 0 0 0 0 0 -27 0 0 0 0 0 0 0 1 -26 0 0 0 0 0 0 0 0&#92;x0d&#92;x0a

The first three 0's are status of the device itself, then the next group of 9 (not including spaces) are individual channel data. So channel 1 = 0 1 0 0 0 0 0 0 0
channel 2 = -44 0 0 0 0 0 0 0 0
channel 3 = -27 0 0 0 0 0 0 0 1
channel 4 = -26 0 0 0 0 0 0 0 0

the first set of chars before the first space can be 0...-100, all the other data is a single byte.

My method is using REMOVE statements like below
status1 = ATOI(REMOVE("&#92;x20", rx$);
status2 = ATOI(REMOVE("&#92;x20", rx$);
status3 = ATOI(REMOVE("&#92;x20", rx$);

Attenuation[1] = REMOVE("&#92;x20", rx$);
ch1Clip[1] = ATOI(REMOVE("&#92;x20", rx$);
etc.,

all the way through the string. Not sure if it's even worth going through breaking up the string into channel groups and working on it that way. What do you think, splitting hairs?

Yeah, right, the string is not always the same, like I said, the attenuation value can be from 1 to 4 bytes long, for each channel. I was thinking of getting the LEN of the attenuation data, then MID the string based on that but seems more work than the removes anyway.

--- In Crestron@..., "jrw_96" <jrw_96@> wrote:

Use a buffer and collect everything in said buffer. Then just break it down as necessary. Only if the incoming strings are predictable and/or the end of the string is always &#92;x0d&#92;x0a...

If the above is true then this should be gravy for you. It's when you do NOT have set points (delimiter(s) and actual sub-headers differentiating the substring/channel info) [always seems to be my case with crc's and what not] that you have to wonder "is this really worth it" imo...

JRW

--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@> wrote:

Here's the string

0 0 0 0 1 0 0 0 0 0 0 0 -44 0 0 0 0 0 0 0 0 -27 0 0 0 0 0 0 0 1 -26 0 0 0 0 0 0 0 0&#92;x0d&#92;x0a

The first three 0's are status of the device itself, then the next group of 9 (not including spaces) are individual channel data. So channel 1 = 0 1 0 0 0 0 0 0 0
channel 2 = -44 0 0 0 0 0 0 0 0
channel 3 = -27 0 0 0 0 0 0 0 1
channel 4 = -26 0 0 0 0 0 0 0 0

the first set of chars before the first space can be 0...-100, all the other data is a single byte.

My method is using REMOVE statements like below
status1 = ATOI(REMOVE("&#92;x20", rx$);
status2 = ATOI(REMOVE("&#92;x20", rx$);
status3 = ATOI(REMOVE("&#92;x20", rx$);

Attenuation[1] = REMOVE("&#92;x20", rx$);
ch1Clip[1] = ATOI(REMOVE("&#92;x20", rx$);
etc.,

all the way through the string. Not sure if it's even worth going through breaking up the string into channel groups and working on it that way. What do you think, splitting hairs?

Yeah, right, the string is not always the same, like I said, the attenuation value can be from 1 to 4 bytes long, for each channel. I was thinking of getting the LEN of the attenuation data, then MID the string based on that but seems more work than the removes anyway.

--- In Crestron@..., "jrw_96" <jrw_96@> wrote:

Use a buffer and collect everything in said buffer. Then just break it down as necessary. Only if the incoming strings are predictable and/or the end of the string is always &#92;x0d&#92;x0a...

If the above is true then this should be gravy for you. It's when you do NOT have set points (delimiter(s) and actual sub-headers differentiating the substring/channel info) [always seems to be my case with crc's and what not] that you have to wonder "is this really worth it" imo...

JRW

--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@> wrote:

Here's the string

0 0 0 0 1 0 0 0 0 0 0 0 -44 0 0 0 0 0 0 0 0 -27 0 0 0 0 0 0 0 1 -26 0 0 0 0 0 0 0 0&#92;x0d&#92;x0a

The first three 0's are status of the device itself, then the next group of 9 (not including spaces) are individual channel data. So channel 1 = 0 1 0 0 0 0 0 0 0
channel 2 = -44 0 0 0 0 0 0 0 0
channel 3 = -27 0 0 0 0 0 0 0 1
channel 4 = -26 0 0 0 0 0 0 0 0

the first set of chars before the first space can be 0...-100, all the other data is a single byte.

My method is using REMOVE statements like below
status1 = ATOI(REMOVE("&#92;x20", rx$);
status2 = ATOI(REMOVE("&#92;x20", rx$);
status3 = ATOI(REMOVE("&#92;x20", rx$);

Attenuation[1] = REMOVE("&#92;x20", rx$);
ch1Clip[1] = ATOI(REMOVE("&#92;x20", rx$);
etc.,

all the way through the string. Not sure if it's even worth going through breaking up the string into channel groups and working on it that way. What do you think, splitting hairs?

Unfortunately not - it's a solid wood orangery with no way to get supply or network cabling..

--- In Crestron@..., "ChrisK" <chris@> wrote:

No 110v electric near by? a wireless cameo KPD would work...


--- In Crestron@..., "Mark" <access@> wrote:

I've got a system with 4 zones of garden lighting which are controlled via Crestron primarily on Mobile & Mobile Pro G.

However, we need to fit a wall station of some description in a location where cabling is impossible to control them as well.

Something like a cameo keypad would be ideal, but they all need cabling of one sort or another (I know there's a battery powered infinet keypad on the cards, but it's not been released yet to my knowledge)

There is a Pro2 nearby, so I'm thinking of a battery powered wireless solution somehow connected to the versiport inputs of the Pro2 and go programatically from there.

Has anyone got any idea of any elegant hardware I could use?

Cheers.
Mark

Use a buffer and collect everything in said buffer. Then just break it down as necessary. Only if the incoming strings are predictable and/or the end of the string is always &#92;x0d&#92;x0a...

If the above is true then this should be gravy for you. It's when you do NOT have set points (delimiter(s) and actual sub-headers differentiating the substring/channel info) [always seems to be my case with crc's and what not] that you have to wonder "is this really worth it" imo...

JRW

--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@> wrote:

Here's the string

0 0 0 0 1 0 0 0 0 0 0 0 -44 0 0 0 0 0 0 0 0 -27 0 0 0 0 0 0 0 1 -26 0 0 0 0 0 0 0 0&#92;x0d&#92;x0a

The first three 0's are status of the device itself, then the next group of 9 (not including spaces) are individual channel data. So channel 1 = 0 1 0 0 0 0 0 0 0
channel 2 = -44 0 0 0 0 0 0 0 0
channel 3 = -27 0 0 0 0 0 0 0 1
channel 4 = -26 0 0 0 0 0 0 0 0

the first set of chars before the first space can be 0...-100, all the other data is a single byte.

My method is using REMOVE statements like below
status1 = ATOI(REMOVE("&#92;x20", rx$);
status2 = ATOI(REMOVE("&#92;x20", rx$);
status3 = ATOI(REMOVE("&#92;x20", rx$);

Attenuation[1] = REMOVE("&#92;x20", rx$);
ch1Clip[1] = ATOI(REMOVE("&#92;x20", rx$);
etc.,

all the way through the string. Not sure if it's even worth going through breaking up the string into channel groups and working on it that way. What do you think, splitting hairs?

Here's the string

0 0 0 0 1 0 0 0 0 0 0 0 -44 0 0 0 0 0 0 0 0 -27 0 0 0 0 0 0 0 1 -26 0 0 0 0 0 0 0 0&#92;x0d&#92;x0a

The first three 0's are status of the device itself, then the next group of 9 (not including spaces) are individual channel data. So channel 1 = 0 1 0 0 0 0 0 0 0
channel 2 = -44 0 0 0 0 0 0 0 0
channel 3 = -27 0 0 0 0 0 0 0 1
channel 4 = -26 0 0 0 0 0 0 0 0

the first set of chars before the first space can be 0...-100, all the other data is a single byte.

My method is using REMOVE statements like below
status1 = ATOI(REMOVE("&#92;x20", rx$);
status2 = ATOI(REMOVE("&#92;x20", rx$);
status3 = ATOI(REMOVE("&#92;x20", rx$);

Attenuation[1] = REMOVE("&#92;x20", rx$);
ch1Clip[1] = ATOI(REMOVE("&#92;x20", rx$);
etc.,

all the way through the string. Not sure if it's even worth going through breaking up the string into channel groups and working on it that way. What do you think, splitting hairs?

Band-aid: PERIODICREBOOT ON

There is a secondary command which changes the time of the reboot, but I can't remember it. It defaults to 2AM apparently, and it's supposed to do it "quietly" without lighting up the screen.

Make sure you report this, please. This is major and I can't believe it's still floating around after many weeks.



On Apr 26, 2013, at 9:06 AM, innoventgroup <innoventgroup@...> wrote:

Fellers,

How to I turn that on... I want to set that up, I cant afford for the panel to die again, now that the customer thinks it is fixed. Thanks Heath for explaining that and, now that you have, I have definitely experienced that scenario. As a matter of fact, I am still experiencing that scenario even after the update on the firmware, just not as dramatic as shutting down my crosspoint. Basically what it is doing now is that the serial and analog signals do not update with the rest of the system. For instance, I can use one of the iPads and change the radio station. Then I can go to another iPad and the station readout will show the updated value. But, when I go to the TSW-750s, I have to press a button to get them to update. Just some additional data for you.

Thanks again!!
DAVE

--- In Crestron@..., Neil Dorin <neildorin@> wrote:

I was mostly referring to the associated reboot fixing it.

Thank to you Heath, I turned periodic reboot on on 80 panels Tuesday and it seems to have helped immensely!

Sent from my iPhone

On 2013-04-25, at 9:14 PM, Heath Volmer <hvolmer@> wrote:

On Apr 25, 2013, at 9:02 PM, Neil Dorin <neildorin@> wrote:

My bet is its the FB bug with the TSWs and the firmware update and resulting reboots corrected it...

I was just going to say that - but do we know that the update actually fixes it? I've been pretty deep into that particular problem and have been asking if it had been fixed. I'll stick with the daily reboots!

Dave, what we're referring to is a lovely bug where the TSW just stops responding to the feedback it's receiving. It transmits fine, but completely ignores all feedback until rebooted or sending in a new program - any activity that resets Core 3. It just appears stuck. Quite elusive. I don't know if I'm experiencing it any more because the panels are now set up to reboot themselves every day...

Heath

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]

No 110v electric near by? a wireless cameo KPD would work...


--- In Crestron@..., "Mark" <access@> wrote:

I've got a system with 4 zones of garden lighting which are controlled via Crestron primarily on Mobile & Mobile Pro G.

However, we need to fit a wall station of some description in a location where cabling is impossible to control them as well.

Something like a cameo keypad would be ideal, but they all need cabling of one sort or another (I know there's a battery powered infinet keypad on the cards, but it's not been released yet to my knowledge)

There is a Pro2 nearby, so I'm thinking of a battery powered wireless solution somehow connected to the versiport inputs of the Pro2 and go programatically from there.

Has anyone got any idea of any elegant hardware I could use?

Cheers.
Mark

I've got a system with 4 zones of garden lighting which are controlled via Crestron primarily on Mobile & Mobile Pro G.

However, we need to fit a wall station of some description in a location where cabling is impossible to control them as well.

Something like a cameo keypad would be ideal, but they all need cabling of one sort or another (I know there's a battery powered infinet keypad on the cards, but it's not been released yet to my knowledge)

There is a Pro2 nearby, so I'm thinking of a battery powered wireless solution somehow connected to the versiport inputs of the Pro2 and go programatically from there.

Has anyone got any idea of any elegant hardware I could use?

Cheers.
Mark