SWITCH...CASE vs SELECT...ACTIVE
richardherman
not-so-junior member
Today I got caught by a problem that, after some debugging, came down to this:
A 'SWITCH...CASE' does not work after a WAIT, while a 'SELECT...ACTIVE' does.
If you execute the above function, the 'SELECT...ACTIVE' works fine, while the 'SWITCH...CASE' throws errrors:
Line 4 2017-07-18 (23:13:44.244):: Assign Stack Ref Error - Out of range
Line 5 2017-07-18 (23:13:44.245):: SetVariable - Error 2 Tk=0x1005
Line 6 2017-07-18 (23:13:44.247):: DoNumberExpression - Error 2 Tk=0x2008 Line=46
Line 7 2017-07-18 (23:13:44.247):: GetNumber - Error 1 Tk=0x0000
Line 8 2017-07-18 (23:13:44.250):: DoNumberExpression - Error 2 Tk=0x2008 Line=50
Line 9 2017-07-18 (23:13:44.250):: GetNumber - Error 1 Tk=0x0000
If you remove the WAIT, both options work fine. Of course this code snippet is not how it appears in the real program.
Is this expected behaviour? If so, which is 'correct'? I can't imagine that today would be the first time I used a SWITCH...CASE after a WAIT . Could it be that this has changed in a recent firmware?
I ran into this on a NX processor with the latest firmware and tested the code snippet on a NI-3100 with v4.1.419 firmware
A 'SWITCH...CASE' does not work after a WAIT, while a 'SELECT...ACTIVE' does.
DEFINE_FUNCTION fnEndCeremony()
{
WAIT 20
{
SELECT
{
ACTIVE (nEditorPlayerMode == PLAYERMODE):
{
SEND_STRING dvCMP, 'blabla_active_playermode'
}
ACTIVE (nEditorPlayerMode == EDITORMODE):
{
SEND_STRING dvCMP, 'blabla_active_editormode'
}
}
SWITCH (nEditorPlayerMode)
{
CASE PLAYERMODE:
{
SEND_STRING dvCMP, 'blabla_switch_editormode'
}
CASE EDITORMODE:
{
SEND_STRING dvCMP, 'blabla_switch_playermode'
}
}
}
}
If you execute the above function, the 'SELECT...ACTIVE' works fine, while the 'SWITCH...CASE' throws errrors:
Line 4 2017-07-18 (23:13:44.244):: Assign Stack Ref Error - Out of range
Line 5 2017-07-18 (23:13:44.245):: SetVariable - Error 2 Tk=0x1005
Line 6 2017-07-18 (23:13:44.247):: DoNumberExpression - Error 2 Tk=0x2008 Line=46
Line 7 2017-07-18 (23:13:44.247):: GetNumber - Error 1 Tk=0x0000
Line 8 2017-07-18 (23:13:44.250):: DoNumberExpression - Error 2 Tk=0x2008 Line=50
Line 9 2017-07-18 (23:13:44.250):: GetNumber - Error 1 Tk=0x0000
If you remove the WAIT, both options work fine. Of course this code snippet is not how it appears in the real program.
Is this expected behaviour? If so, which is 'correct'? I can't imagine that today would be the first time I used a SWITCH...CASE after a WAIT . Could it be that this has changed in a recent firmware?
I ran into this on a NX processor with the latest firmware and tested the code snippet on a NI-3100 with v4.1.419 firmware
Comments
-
Is nEditorPlayerMode a instance variable or defined in DEFINE_VARIABLE?
-
Is nEditorPlayerMode a instance variable or defined in DEFINE_VARIABLE?
It's a global variable, defined in DEFINE_VARIABLE.
'PLAYERMODE' and 'EDITORMODE' are constants, defined in DEFINE_CONSTANT. 'EDITORMODE' = 1 and 'PLAYERMODE' = 2 -
Post all the code. There are bugs with switch statements that have nothing to do with WAITs that you are likely running into.
I wouldn't write code like that though. I would put the wait where the function is called, or preferably, not use one at all.
Paul -
Post all the code.
There is no more code needed than posted above: run that function and the SWITCH...CASE fails.
Like I wrote: the code isn't like the example snippet. It is a simplification that still shows the problem. it is just to make it easier to reproduce it.
-
As a general rule I do not put any code in a function inside a wait that calls upon any variables. I might do something discrete. I like a_riot42's suggestion of doing the wait somewhere else. We use functionin Netlinx in a somewhat different way than most other languages. In other languages functions tend not to get as big as ours. In fact large functions are considered less desirable. While I don't necessarily agree with this notion, I do think it is a good idea to keep timing stuff out of functions. They're just not really built for it. We can get away with it occasionally.
-
I noticed at some version of netlinx that I couldnt use constants for cases, so I just hard-coded them. See if that has any effect. And I agree with the above about the wait, and I hear you it's a simplification I just try to use as little waits as possible.
-
I noticed at some version of netlinx that I couldnt use constants for cases, so I just hard-coded them. See if that has any effect. And I agree with the above about the wait, and I hear you it's a simplification I just try to use as little waits as possible.
Interesting. I always use constants in Switch/Case. I have no code I've written in almost 10 years that this is not the case. I've not had any issue with it. -
richardherman wrote: »
Is this expected behaviour? If so, which is 'correct'? I can't imagine that today would be the first time I used a SWITCH...CASE after a WAIT . Could it be that this has changed in a recent firmware?
This has been a known issue for a long time.
See tech note 736.
http://trade.amx.com/techsupport/techNote.asp?id=736 -
This has been a known issue for a long time.
See tech note 736.
Thanks!. that was what I was looking for. Seeing the tech note is dated november 2005, this probably won't be fixed ever.....
I probably did not ran into this before, because I usually do WAITS a little different, more like Paul wrote. If I do that in this situation (put the wait where the function is called) the SWITCH...CASE runs, although you could argue it is still inside a WAIT.
@MLaletas: Replacing the constants with hard coded values, does not help.
Anayway, thanks to all for the input.
Richard
-
ericmedley wrote: »
Interesting. I always use constants in Switch/Case. I have no code I've written in almost 10 years that this is not the case. I've not had any issue with it.
I know, I dont understand what the probem is using them, I used it for a couple years and I remember updating my software and after that I couldnt use constants in there, so ever since then I stopped using them. -
I know, I dont understand what the probem is using them, I used it for a couple years and I remember updating my software and after that I couldnt use constants in there, so ever since then I stopped using them.
It seems like around half the common practices I use coding Netlinx center around some version of this: "Well. it didn't work right in that situation or version, so I developed the habit of doing it this other way."
Long live Netlinx and Netlinx compiler!
-
If you try the 'switch ... case' wait thing on a nx processor it crashes it!
-
If you try the 'switch ... case' wait thing on a nx processor it crashes it!
That also happended to me. When I noticed the problem it was on a NX-3200. It either completely locked up the processor (power cycle needed) or suddenly rebooted. On a NI processor nothing much happens, except it doesn't run the code and throws up errors, of course. It never crashes.
Just one of those 'subtle' differences between the NetLinx family members, I guess...
Categories
- All Categories
- 2.5K AMX General Discussion
- 922 AMX Technical Discussion
- 514 AMX Hardware
- 502 AMX Control Products
- 3 AMX Video Distribution Products
- 9 AMX Networked AV (SVSI) Products
- AMX Workspace & Collaboration Products
- 3.4K AMX Software
- 151 AMX Resource Management Suite Software
- 386 AMX Design Tools
- 2.4K NetLinx Studio
- 135 Duet/Cafe Duet
- 248 NetLinx Modules & Duet Modules
- 57 AMX RPM Forum
- 228 MODPEDIA - The Public Repository of Modules for Everyone
- 943 AMX Specialty Forums
- 2.6K AMXForums Archive
- 2.6K AMXForums Archive Threads
- 1.5K AMX Hardware
- 432 AMX Applications and Solutions
- 249 Residential Forum
- 182 Tips and Tricks
- 146 AMX Website/Forums