Thanks for testing this and reporting your results. It sounds like the problem from the original post is specific to the project or IR file.
I personally use SEND_COMMAND dvDEV," 'SP',nDigit" like you, but I do agree all documented commands should work without error or exception.
Just a little history lesson... The CH and XCH commands were added as a way to off-load IR pulse management from the Master about the time the Synergy classroom application (early 90s) was released. Previously you would have to code an IR preset macro similar to below:
I have 3 masters in the field now with the latest firmware and 1 out of the 3 the firmware broke the XCHM command. I made a similar call as above and the fixed the problem. I dont see any reason why only 1 out of the 3 stopped working, but regardless it did. In each case these were jobs that have been installed and working well from 6 months to 2 years.
I have 3 masters in the field now with the latest firmware and 1 out of the 3 the firmware broke the XCHM command. I made a similar call as above and the fixed the problem. I dont see any reason why only 1 out of the 3 stopped working, but regardless it did. In each case these were jobs that have been installed and working well from 6 months to 2 years.
Tim,
Do all three systems use the same IR file? If so, which file? Or which IR file is causing the problem?
Yeah! I know some people are using the latest firmware without problems, but the strange thing is that it might work for a few days or weeks and then you have a erratic or locked IR port. It may not happen with all masters as well, but in my case 3 NI-3000 and 1 NI-4000 it did.
I believe that a similar DEFINE_CALL as above or any other secure measure should be implemented in the next device firmware release. Last week I had one NI-3000 running under v118 controlling a Lutron Grafikeye via IR with the default IR file from the standard AMX IREdit database that locked up. This project was running without a problem for 6 months. For now my solution is to use v115 on all NI masters.
I seriously doubt that it has anything to do with the IR driver...unless the IR driver gets corrupted by the new firmware. XCHM was broken on 2 different ports and 2 different IR drivers where before I upgraded it was working fine.
Foe the NI3000 that XCHM broke on, I was using IR ports 5 and 6. The ones that it seemed to work fine I was using IR port 1 on an NI2000 and on port 1 on an NI3000.
I seriously doubt that it has anything to do with the IR driver...unless the IR driver gets corrupted by the new firmware. XCHM was broken on 2 different ports and 2 different IR drivers where before I upgraded it was working fine.
I believe it is a timing issue with certain IR drivers.
It was to an MRA DSS receiver, there was no video on the receiver, so I cant say for sure. However it seemed like it was missing digits, likely the first 2 digits. However at the same time, I watched the IR port flash 3 times as it should have.
I have not tried version 136 as of yet. But as Dave Hawthorne stated, the issues are not ones that necessarily show up in a simple test. I have 4 sites in a row all seem to work just fine with version 118. And then all IR stops or at least stops on certain ports. I didn't try to send a CP to clear the que's, but in every case, version 115 fixed the problem and it never returned. I think the only issue I have seen with 115 pertains to custom IR files with IR in slots above 100. I don't normally go there so this isn't anything that I can say for sure.
On the other hand, if AMX releases 136 as a new firmware, then programmers should not have to re-write code for it to work. If programmers are reporting that their XCM or XCHM commands that were running fine are no longer working simply by rolling the revision, then I think this is something that AMX should address.
I'm reasonably sure AMX is addressing it. My experience is that they tend to be very quiet about bug fixes until they are fixed. A one-to-one talk with support might get you an unofficial admission they are aware of a problem and working on it, but I don't expect official acknowledgements or status reports until it is a fait accompli.
I am glad to hear that AMX is working on a fix. IR port management should be a top priority since it is probably the most used interface in most projects.
The XCHM commands are very handy specially when you need to manage multiple sats and cable boxes. For now v115 is the ticket for me until a new firmware fixes this problem. Some people are reporting no problems with v136, but I wonder if it will run for a while and then crash the IR port like v118.
In may case the XCHM works fine under v115 and v118, but v118 has crashed on me on a couple IR ports after a couple months. So I have everything back to v115. v136 glitched right away with the same IR files that worked fine under v115 and v118 while using XCHM.
I hope the new firmware will include some type of built in call that handles better the IR timing and is not sensitive to the IR files themselves.
Well, the new NI device firmware 1.12.140 didn't fix my XCHM commands. It still misses the first digit. When I send 922, it misses the 9 and ends up sending only 22. I downgraded it back to v115 and it works flawless. The IR port flashes the correct number of times, but for some reason the first digit gets corrupted.
Unfortunately, it didn't cut for me yet. I wonder why it works fine under v115, same code, same IR file. Who knows. Attached is the Cable Box IR File I use in my home NI-3000. I do use a structure to load all channel numbers, this way when the line up changes, I just need to change the text file, no need to change the TP channel numbers. Again, why it works fine under v115 and v118??? Who knows. Since v115 doesn't lock up the port like v118, it is still the champ for me.
Well, the new NI device firmware 1.12.140 didn't fix my XCHM commands. It still misses the first digit. When I send 922, it misses the 9 and ends up sending only 22. I downgraded it back to v115 and it works flawless. The IR port flashes the correct number of times, but for some reason the first digit gets corrupted.
Unfortunately, it didn't cut for me yet. I wonder why it works fine under v115, same code, same IR file. Who knows. Attached is the Cable Box IR File I use in my home NI-3000. I do use a structure to load all channel numbers, this way when the line up changes, I just need to change the text file, no need to change the TP channel numbers. Again, why it works fine under v115 and v118??? Who knows. Since v115 doesn't lock up the port like v118, it is still the champ for me.
Sincerely,
Ricardo
This is a case where I would tentatively suggest that perhaps what was broken in older versions made it work, and fixing it broke it in some applications. When digits are missed, it is very often one of two things: the pulse is too long, or the IR is too strong and flooding the device. The new Direct-TV/Tivo devices are notorious for being sensitive to strong IR, and many cable boxes are as well ... I believe they have tried to make the IR more sensitive to allow for plasma screen emissions, and the result is that an emitter stuck right over the sensor overpowers it. I have had reasonable success sticking the emitter as far as an inch and a half away from the sensor.
That said, I have somewhat lost confidence in these NI firmware updates, and barring the above possibility, wouldn't exactly be shocked if there is still an issue.
Well, the new NI device firmware 1.12.140 didn't fix my XCHM commands. It still misses the first digit. When I send 922, it misses the 9 and ends up sending only 22. I downgraded it back to v115 and it works flawless. The IR port flashes the correct number of times, but for some reason the first digit gets corrupted.
Ricardo, in preliminary testing here we are unable to duplicate this with mode 2 or mode 0.
Can you tell us whether you were running Duet Master firmware v3.12.332, or non-Duet Master firmware v2.32.148? Using one of these master versions is required to ensure all fixes work correctly.
Also, can you confirm which XCH Mode you are using?
I'm guessing mode 2, but you may also be using 0 or 1 since your IR file doesn't have an Enter function.
The XCH command now requires a space between the XCH and the number.
The documentation for the command shows the space - but even so the older version worked without the space in the NI-x000, as an undocumented feature.
Ricardo's code does not have the space - so the first digit is ignored when using the new firmware.
In the process of fixing the XCH issues the Engineers went strictly by the documented syntax in implementing the commands.
The XCH syntax (going all the way back to the AXB-TM5) has a space between the XCH and the number, so that's what it is...
Guy is correct, the XCH command does require the space between the XCH and the channel number, like:
SEND_COMMAND IR_DEVICE,"'XCH 343'"
My structure code didn't have the space. Even though it was working for v115 and v118 without the space on multiple projects, the new firmware DOES require the space. I uploaded the new firmware v140 again and corrected my code and now it works fine. I will run the new firmware on my home system, and as long as it doesn't lock up the IR port, it is a winner!
I would like to thank Guy Minervini for detecting my error and everyone else that participated in this thread. I apologize for my previous message stating that the firmware didn't work. A learned a big lesson: " Always pay attention to the Software History, and follow guidelines strictly". Again, thanks everyone.
Comments
Thanks for testing this and reporting your results. It sounds like the problem from the original post is specific to the project or IR file.
I personally use SEND_COMMAND dvDEV," 'SP',nDigit" like you, but I do agree all documented commands should work without error or exception.
Just a little history lesson... The CH and XCH commands were added as a way to off-load IR pulse management from the Master about the time the Synergy classroom application (early 90s) was released. Previously you would have to code an IR preset macro similar to below:
Define_Device TV_IR = 8 Define_Variable TV_Lock Define_Call 'TV Preset' (nDigit1,nDigit2,nDigit) { ON[TV_Lock] Pulse[TV_IR,nDigit1] Wait 10 Pulse[TV_IR,nDigit2] Wait 20 Pulse[TV_IR,nDigit3] Wait 30 OFF[TV_Lock] }The down side here is that if multiple TVs are in the system, you would a separate Define_Call for each TV device.Tim,
Do all three systems use the same IR file? If so, which file? Or which IR file is causing the problem?
Do all three systems use the same IR port?
Brian
I believe that a similar DEFINE_CALL as above or any other secure measure should be implemented in the next device firmware release. Last week I had one NI-3000 running under v118 controlling a Lutron Grafikeye via IR with the default IR file from the standard AMX IREdit database that locked up. This project was running without a problem for 6 months. For now my solution is to use v115 on all NI masters.
Ricardo
Foe the NI3000 that XCHM broke on, I was using IR ports 5 and 6. The ones that it seemed to work fine I was using IR port 1 on an NI2000 and on port 1 on an NI3000.
I believe it is a timing issue with certain IR drivers.
Are you missing digits or does the port lock up?
On the other hand, if AMX releases 136 as a new firmware, then programmers should not have to re-write code for it to work. If programmers are reporting that their XCM or XCHM commands that were running fine are no longer working simply by rolling the revision, then I think this is something that AMX should address.
Just my thoughts.
Sheldon Samuels
IPS Resources
The XCHM commands are very handy specially when you need to manage multiple sats and cable boxes. For now v115 is the ticket for me until a new firmware fixes this problem. Some people are reporting no problems with v136, but I wonder if it will run for a while and then crash the IR port like v118.
In may case the XCHM works fine under v115 and v118, but v118 has crashed on me on a couple IR ports after a couple months. So I have everything back to v115. v136 glitched right away with the same IR files that worked fine under v115 and v118 while using XCHM.
I hope the new firmware will include some type of built in call that handles better the IR timing and is not sensitive to the IR files themselves.
Lets all cross our fingers!
Ricardo
Just a FYI
Paul
Thanks for the heads up.
Well, the new NI device firmware 1.12.140 didn't fix my XCHM commands. It still misses the first digit. When I send 922, it misses the 9 and ends up sending only 22. I downgraded it back to v115 and it works flawless. The IR port flashes the correct number of times, but for some reason the first digit gets corrupted.
Unfortunately, it didn't cut for me yet. I wonder why it works fine under v115, same code, same IR file. Who knows. Attached is the Cable Box IR File I use in my home NI-3000. I do use a structure to load all channel numbers, this way when the line up changes, I just need to change the text file, no need to change the TP channel numbers. Again, why it works fine under v115 and v118??? Who knows. Since v115 doesn't lock up the port like v118, it is still the champ for me.
Sincerely,
Ricardo
That said, I have somewhat lost confidence in these NI firmware updates, and barring the above possibility, wouldn't exactly be shocked if there is still an issue.
I dont understand why we are the ones who have to suffer through this QC process!!!!!!!!!!
Ricardo, in preliminary testing here we are unable to duplicate this with mode 2 or mode 0.
Can you tell us whether you were running Duet Master firmware v3.12.332, or non-Duet Master firmware v2.32.148? Using one of these master versions is required to ensure all fixes work correctly.
Also, can you confirm which XCH Mode you are using?
I'm guessing mode 2, but you may also be using 0 or 1 since your IR file doesn't have an Enter function.
The XCH command now requires a space between the XCH and the number.
The documentation for the command shows the space - but even so the older version worked without the space in the NI-x000, as an undocumented feature.
Ricardo's code does not have the space - so the first digit is ignored when using the new firmware.
In the process of fixing the XCH issues the Engineers went strictly by the documented syntax in implementing the commands.
The XCH syntax (going all the way back to the AXB-TM5) has a space between the XCH and the number, so that's what it is...
SEND_COMMAND IR_DEVICE,"'XCH 343'"
My structure code didn't have the space. Even though it was working for v115 and v118 without the space on multiple projects, the new firmware DOES require the space. I uploaded the new firmware v140 again and corrected my code and now it works fine. I will run the new firmware on my home system, and as long as it doesn't lock up the IR port, it is a winner!
I would like to thank Guy Minervini for detecting my error and everyone else that participated in this thread. I apologize for my previous message stating that the firmware didn't work. A learned a big lesson: " Always pay attention to the Software History, and follow guidelines strictly". Again, thanks everyone.
Ricardo