GET_LAST: New Firmware
jjames
Posts: 2,908
Okay, who's going to test this out? Per the newest firmware release today:
I can see the temptation to run out and upgrade your firmware just so you can do this - but someone's gotta test this out before I jump on board. Specifically - what happens when one user is ramping the volume, and another panel comes in and ramps as well? Or one panel is setting a preset, and then someone else comes in and goes to set a preset that calls a function - which value gets passed to the function? To me, this was one of the GET_LAST's biggest drawback, and because of it - in my code there are VERY few HOLD events.
I can't test as I'm without a master. Anxious for the results.
AMX Firmware wrote:Fixed I2C communications issue for RS232/485 communication errors
Fixed Java based logging to ensure consistent log output
Added security profile configuration
Fixed HTTPS interface to be more reliable
Fixed GET_LAST so it works within a HOLD event for both dev array and channel array
I can see the temptation to run out and upgrade your firmware just so you can do this - but someone's gotta test this out before I jump on board. Specifically - what happens when one user is ramping the volume, and another panel comes in and ramps as well? Or one panel is setting a preset, and then someone else comes in and goes to set a preset that calls a function - which value gets passed to the function? To me, this was one of the GET_LAST's biggest drawback, and because of it - in my code there are VERY few HOLD events.
I can't test as I'm without a master. Anxious for the results.
0
Comments
Very cool. I knew if I was lazy enough this problem would just go away without me ever having to do anything but upgrade firmware.
Thank goodness they also fixed that 7th IR port that refuses to light up during the startup light show. That's been pissing me off for months.
Paul
So do they store the GET_LAST value in a hold in a var specifically for that event table? If this is what they do, do they also create an array to hold the GET_LAST value for every TP that is declared for that event table? If it's just a single "HOLD" var for each event table I'm not sure if that's a good enough solution.
So does GET_LAST in a hold just return the last channel to trigger an event for that event table or does it return the last channel to trigger an event for a specific TP in that event table? If the event table is created for 6 TP's can we have 6 simultaneous HOLDs?
Instead of acting on the HOLD with the previous PUSH data, they are holding off the event generation until the HOLD parameters are met. That would be how I figure it.
This is basically I do my holds presently. In the PUSH based on the GET_LAST TP index and GET_LAST channel index I add that last channel number to the TP's index position of a nDevHOLDArray. I clear it upon the release, again by use of the GET_LAST TP index and then in the hold if at least one array postion has a value I'll loop through the array and act on the channel number contained there in for each index position if it holds a value other than 0.
But that's what I'm saying ... the event itself doesn't actually fire until the parameters are met. No stored value at all. That's why it required a firmware update, the hardware has to be able to know what the HOLD timer is to do this.
Perhaps, I'm not understanding something here. This is how I expect to do this under the new firmware.
I'm not sure what the issue is. A hold event is just another event. In the scheme of things, it's no different from an push or a release. Isn't the stack_var remade each time the particular event fires? So, even on a repeat, it's just made anew each time. isn't this so? A hold occurs because you haven't let go of the button yet. You should still have that info available, even if you hold it for a long long time. The hardware isn't what creates the hold event. It's the software on the master knowing that it hasn't seen a release from device X yet. Isn't this so?
I'd be interested to know if this new GET_LAST modification allows the same functionality w/o all the extra code or is it just a change in the GET_LAST scope from global to local?
This example is just a 3 second hold to set a TPs permissions. It uses the repeat just to allow a counter to control event triggering for each TP that may hold. Again not very likely but.....
Now if I don't have to go through this anymore I'll be very happy.
Okay, now I see. I knew that too. I don't know what my confusion was. Oh well.
Perhaps they need a Get_Last_This_Button_Event() keyword.
Isn't that what this firmware change does?
Most of the time I think 1 per event table would be sufficient but there are times when multiple TPs/users will be on the same device page pushing different buttons at the same time so one users get_last shouldn't affect another user.
Hopefully one of those smart fellas from AMX will shed us some light.
Test Code:
When I set the variable in debug to run the code I should get index returns of 1 for TP 10001, 2 for 10002, 3 for 10003 & 4 for 10004.
Test 1 which ran just test 1: Works great!
Run Test 1 & 2 at the same time: Let's run all 4 tests: As you can see it works freakin great! Tracks the last pushed or currently held button for each TP in an event table, while all are running at the same time. Multiple holds in each event table and multiple holds in several event tables.
I can't imagine there being any issues using this now in a hold.
Good job guys!!!!!!!!!!
This deserves 5 smiley faces.
Looks good though - this could be a very nice thing!
Yeah, me too. To me this sounds like a 'going forward' type thing. Not an 'updating the old stuff all at once' thing.
Does that make any sense?
Obviously untested, but the idea is to see if the correct variables are incremented & decremented. In order to see - have one panel go up, the other go down.
Results when running test 1: Running the 3 test at the same time: VALUE KEY:_____
TP 10001 = 1xxx
TP 10002 = 2xxx
TP 10003 = 3xxx
TP 10004 = 4xxx
TEST 1 = x1xx
TEST 2 = x2xx
TEST 3 = x3xx
TEST 4 = x4xx
VALUES = xx?? (where ?? = some value)
Okay, after a long day - I've finally put this to test. One of the reasons why I abandoned HOLD statements in code (unless it was for a single panel only) was the fact that if one panel was HOLDing, and another panel came in - the GET_LAST values were of that of the last panel that entered.
There was a work around posted here: http://www.amxforums.com/showpost.php?p=39440&postcount=23, this worked perfectly and perhaps would be considered a "more elegant" approach. Because it worked, this has been the approach I've taken over the past several years.
Before this firmware, the following code would choke.
However, now it works perfectly. Here are the results when two panels start to HOLD (panel one volumes up, panel two volumes down.) This snippet here shows that it works with two panels from one array and two different buttons from another array.
Note: Tested on an NI-700
On line one, panel 2 volumed down alone. On line six, panel 1 volumed up alone. On line 11, panel 2 volumed down until line 15 when panel 1 joined going in the opposite direction.
This works how I expected GET_LAST to work in a HOLD, though never has until now. I plan on using this in my upcoming "very large" job. I of course will have a backup plan should this not work for whatever reason, but I do not expect having to call up "Plan B."
Kudos goes to the firmware engineers at AMX. I have not tested any other "fixes" or "features" of this new firmware, so it might be a little early to say it's perfect - but this alone has me sold until (hopefully not) a "show stopper" is found (highly unlikely.)
Next up: GET_LAST for a TIMELINE_EVENT.
Paul
Now if you could just change the way ip_server_open works that would make my day. Currently after a connection is made the port goes offline and stays offline and needs to be reopened. All the normal server sockets I know stay open and listening until they are closed programmtically. For some reason AMX server sockets operate differently and are closed automatically after a read is done from the socket.
Paul
Sorry, late getting to this thread. The GET_LAST for HOLD issue was solved in the FW by retaining a snapshot of the GET_LAST indexes from the push event inside the constructs keeping track of each extended push (i.e. hold) so that when the HOLD duration triggers, the original indexes are available for retrieval by the GET_LAST call.
And on the side note regarding IP_SERVER_OPEN, yes, I would agree that NetLinx Server sockets don't work like server sockets in other languages. But given the single threaded architecture of NetLinx and its D:P:S centric communication methods the existing APIs seemed the most logical approach to providing Server Socket functionality to a user group that might not be the most versed in network programming. The approach was taken that each IP_SERVER_OPEN and the D:P:S associated with it represents a "potential" connection by a client. Until that connection is made, an IP_SERVER_CLOSE on the D:P:S will close the servers socket. But once a client socket accept occurs in the underlying firmware, the client socket is then tied to the D:P:S leaving no ties to the original server socket...so it must be closed. If it was not closed and something happened on the underlying server socket, there would be no way to relay this back to the NetLinx application (ONERROR) since the D:P:S is now tied to the client socket. This approach still allows multiple "potential" connections on the same IP port by calling IP_SERVER_OPEN with different D:P:S's using the same IP port, thereby allowing 'x' simultaneous connections. But it does require the user oversee the management of "potential" connections and their D:P:S's directly. (opening, closing, etc)
Thanks for the insight. Yes with one thread, a multi-threaded server isn't really possible. Is writing server code in Duet any better than Netlinx? I wonder if Java's socket functionality would help with this kind of issue.
Paul
Cool, thanks I will check that out.
Paul