No, you do not need to keep the IP_RX$. This is because EVENT (if you look up the help this is explained) is triggered for ALL external events; that is to say, when new data arrives on IP_RX$ **or** any other input on the module changes.
This is why it burns needless CPU cycles; it will actually attempt to read data from the buffer every time a different input is used. It should, however, work around the original problem :-)
Cheers,
-noob
toggle quoted message
Show quoted text
--- In Crestron@..., "mdsmoker" <mdsmoker@...> wrote:
Thanks for the help, I'll give that a try when I get a chance. One question, on line 2849 when replacing "change" with "event" I'm guessing I still need to keep the variable name "IP_RX$"? So that line would be:
"event IP_RX$"
Sorry if that seems like a stupid question, but I haven't touched S+ until now so I want to be sure.
Thanks again
--- In Crestron@..., "Crestron Noob" <crestronoob@> wrote:
Most likely, yes.
Can't think of a "very easy" guaranteed fix for this particular module; try this and TEST if it works. I'm pretty sure it will solve the original problem, the question is exactly how many new ones are introduced.. ;-)
1) Open the Autonomics MMS IP Processor v3.1 module in S+ editor (right-click, edit user module). It's located inside "Autonomics MMS V3.1", you need to open that first
2) Once you see the SIMPL+ code, hit Ctrl-G and type 2849 in the dialog, then OK. This will move your cursor to line #2849, which should say "change IP_RX$".
Once you've gotten here, you will need to make some modifications. The new code should look like this: -- changes are done on lines 2849 (now says "event"), 2859 (now says "remove" instead of "gather") and 2860 (has "if (len(In$))" prepended).
Hit F12 to recompile the module; make sure no errors are generated in the compile log at the bottom. If the module seems to operate normally after this, you are most likely good to go. If it exhibits strange/non-acceptable behavior, then a more complex modification is needed (you'll have to revert to the original module for now)
Also note that this technique will cause the module to burn (needless) CPU cycles; probably will not be noticeable in practice, but at least I mentioned it..
HTH,
-noob
--- In Crestron@..., "mdsmoker" <mdsmoker@> wrote:
So is this error what's causing the Pro2 to stop communicating with the Mirage? Here's a link to 3.1...
--- In Crestron@..., "Crestron Noob" <crestronoob@> wrote:
Hi, this message is usually due to a bug in 2-series firmware. I could not find version 3.1 of the MMS module for download, if you can link it, I may be able to suggest a quick fix.
Happy new year,
-noob
--- In Crestron@..., "mdsmoker" <mdsmoker@> wrote:
So I'm having this ongoing problem controlling a Mirage Media Server. I'm using their newest module (3.1) and a Pro2. After a week-10 days of uptime, the following error pops up and the Pro2 stops communicating with the Mirage:
Error: Module S-4.5.15.2.1:S-24 : S2_Autonomic_MMS_IP_Processor_v3_1 at line 1538: Could not allocate local storage. Terminating
TimeStamp: 14:18:48 12-25-12 UpTime: 10 days 00:21:18.54 Task: S07700b
I'm a noob when it comes to programming, but I have done several projects integrating the Mirage and haven't run into this problem before. This is an older project that I didn't program originally. I'm simply adding this as a source. The program is stored on the CF card, not sure if that has anything to do with it.
Any advice would be great!
