AMX - Please fix the console
Auser
Posts: 506
in AMX Hardware
Argh. So I'm spending my Saturday night back on the tools writing code (mistake number 1) after a fair while away from the world of NetLinx masters. Luckily I've been able to sit on the sidelines and not get "caught up" in the introduction of the DVX equipment (I censored myself heavily here - those who've been installing it know what I mean).
Mistake number two is thinking, "I'll just add in VC support in the room with the Cisco C40 and I'll go home to have some amount of Saturday evening off".
Here begins my pain:
- I'm not a fan of AMX provided Duet modules for various reasons, but I'm not going to spend my night writing a fully featured NetLinx module for a VC codec so it looks like I've got no choice but to use one. A search in the third party modules on the AMX website shows a C40 Duet module available. Only an IR file is available for download though. Stuffed up permissions on the C40 download?
No worries thinks I and downloads a C60 module which should work for the most part.
- I add it to my code, recompile, send the program over and voila! Nothing works. And I mean nothing. No master to master communications. No access to the file system from NetLinx modules reading in config files. Everything died in the butt.
I didn't think to check the Duet memory allocation/usage but honestly a master new out of box should be able to run two Duet modules without needing to twiddle with settings.
- Um, I suppose I better load the latest firmware (v4) and I really, really don't want to. No choice, so I do. And everything works again. Except the console output. ARGHH.
I rarely use debug/control a device when I'm coding and tend to rely on console commands and output. However AMX in their wisdom have broken the console output in v4. I noticed this on the Enova masters and assumed this was a "feature" in this very beta product lineup.
Basically msg on works, but msg on 2 or msg on warning etc. all spew forth all console messages the same as msg on. This sounds like a little thing, but it causes serious issues for me as a programmer.
AMX please fix ASAP. And for crying out load, open source your third party modules where there aren't legal confidentiality reasons to not do so. I'm going home to drink and will have to come back tomorrow to try rolling back the firmware and stuffing around with the Duet memory allocation to see if that is the culprit of the original problem.
Mistake number two is thinking, "I'll just add in VC support in the room with the Cisco C40 and I'll go home to have some amount of Saturday evening off".
Here begins my pain:
- I'm not a fan of AMX provided Duet modules for various reasons, but I'm not going to spend my night writing a fully featured NetLinx module for a VC codec so it looks like I've got no choice but to use one. A search in the third party modules on the AMX website shows a C40 Duet module available. Only an IR file is available for download though. Stuffed up permissions on the C40 download?
No worries thinks I and downloads a C60 module which should work for the most part.
- I add it to my code, recompile, send the program over and voila! Nothing works. And I mean nothing. No master to master communications. No access to the file system from NetLinx modules reading in config files. Everything died in the butt.
I didn't think to check the Duet memory allocation/usage but honestly a master new out of box should be able to run two Duet modules without needing to twiddle with settings.
- Um, I suppose I better load the latest firmware (v4) and I really, really don't want to. No choice, so I do. And everything works again. Except the console output. ARGHH.
I rarely use debug/control a device when I'm coding and tend to rely on console commands and output. However AMX in their wisdom have broken the console output in v4. I noticed this on the Enova masters and assumed this was a "feature" in this very beta product lineup.
Basically msg on works, but msg on 2 or msg on warning etc. all spew forth all console messages the same as msg on. This sounds like a little thing, but it causes serious issues for me as a programmer.
AMX please fix ASAP. And for crying out load, open source your third party modules where there aren't legal confidentiality reasons to not do so. I'm going home to drink and will have to come back tomorrow to try rolling back the firmware and stuffing around with the Duet memory allocation to see if that is the culprit of the original problem.
0
Comments
In one of my classes at AMX someone asked the instructor that same question: Why are the modules released by AMX not open for modification? His answer was that since AMX supports these modules keeping them closed keeps them in a known state, even if that known state has bugs. If the modules were open to modification then people would be tweaking and changing them and every issue would have to start from scratch.
Also, and these are my assumptions, it could be due in part to Duet being a paid class/application. If all the source for their modules were open I'd imagine it wouldn't take long for people to figure out all they needed to know from that.
Plus, AMX doesn't just provide the hardware and language to us. They have their own in-house programmers that develop code for a fee just as we do. I'd imagine many of their modules are developed during and for that purpose. I'm certainly not going to release my source to anyone.
Now that cant be said for the mxp series, which if you instantiate multiple modules, it will send the same command however many times its instantiated, so to fix, when sending a command, you have to use the physical D:P:S for anything over the 1st port. (this may have been fixed in newer releases of the module, but I havent checked)
my .02
With the v4 firmware, the MSG command was changed and now allows for new parameters:
MSG On [error|warning|info|debug]
You can find this and several other changes in the programming guide for v4 Netlinx Controllers:
http://amx.com//assets/manuals/NetLinxControllers.WebConsole-ProgrammingGuide.FMv4.pdf
As for the tandberg module, this module is created and supported by Cisco and not AMX ITG. However, if you have issues with it, our Technical Support team is here to assist and can pass along any module problems to the appropriate group within Cisco. Most modules are written in house here at AMX, but this one specifically is not.
I've been installing them and have no idea what you mean.
The Cisco C Series module is actually developed by Cisco and not AMX. If you want to roll back to the v3.x firmware v1.3.2 of the module (which has been out for over a year) works on it. You can grab it at the cisco developer site, here. https://developer.cisco.com/web/telepresence-developer/integrator-modules/amx-codec-c60c90
Its highly unusual for the AMX site download to actually be a version ahead of the Cisco site, but it appears to be the case at the current time. The older version is compatible with the v4 firmware as well, as far as I know. I have it running on at least 4 DVX-3150 masters.
Hope that helps.
-Ryan
Changed and broken.
For years programmers have relied on logging to the console based around send_string 0 and without any warning AMX has fundamentally and drastically changed the behaviour of this diagnostic mechanism.
Specifically:
- Verbose debugging information from Duet modules now spews forth to the console as soon as msg on <anything> is issued. To prevent this, commands need to be sent to every Duet module incorporated in the workspace telling them to shut up.
- My logging framework which has served me well for years works around the length limitation of text sent to the console by breaking down the text being sent to the console into chunks so that no information is truncated and therefore not displayed.
send_string dvDebugTerminal, "_cPrepend,': '" while(length_array(_cLoggingBuffer)) { if(length_array(_cLoggingBuffer) > MAX_LENGTH_CONSOLE_STRING) send_string dvDebugTerminal, get_buffer_string(_cLoggingBuffer,MAX_LENGTH_CONSOLE_STRING) else send_string dvDebugTerminal, _cLoggingBuffer } send_string dvDebugTerminal, "CR,LF"The content of the logging information is sent as a a separate string to the console after the prepended information regarding the source and severity of the information and a new line is not sent to the console until all of the information has been printed.
Because the msg on 2 setting has been removed, everything is now printed on a separate line with separate timestamp.
This is not an issue when I have msg on to see Duet notifications and any run time errors, but for general diagnostic purposes it's a PITA.
The above shows just how much of a PITA it is.
- It's impossible to see what you're typing in the console because every second or so a Duet module spews random diagnostic information to the console. You can see where I started typing a send_command to a module and was then swamped by guff.
- The debugging info spat out by one of my NetLinx modules is now spread over 4 times as many lines and obscured by time stamps I couldn't care less about.
- Half of the diagnostic information doesn't denote where it has come from. We can make an educated guess based on content and the fact that there is about one Duet module in the above system, but in a large system with many Duet modules it may not be possible to determine the source of individual messages.
I don't understand why the console message mode which only shows messages generated in NetLinx land has been removed from the current firmware, regardless of what AMX is doing with Duet development.
I think AMX has forgotten that 90% of AMX programmers do not work for AMX directly and I would think conservatively 80% of AMX programmers develop in NetLinx as opposed to Duet.
It's all very well and good for AMX to develop debug frameworks for their in house Duet development and change the classes included in the Duet SDK time and time again, but this should not be done to the detriment of their customer base out in the real world.
Sorry typo - I meant DGX equipment (and specifically DXLink connected equipment, though I'm hoping the new DVX's haven't had early issues like the DVX-2100's had).
You're worrying me as I just specced my first DGX frames.
Probably not too bad now - they've settled down a lot from the original hardware/firmware versions. Expect a few quirks and allow a good chunk of extra commissioning time. And remember that they don't have audio breakaway without an external analogue audio switcher and audio breakin/breakout cards in the frame...
This, at least, I caught. That would be a really unpleasant thing to figure out mid job though.