开云体育

+1

SIO w/ incoming string parameter "username:" (or whatever format the prompt is in) triggers another SIO that sends the username back, likewise for "password:"...

- Chip


--- In Crestron@..., Jeremy Weatherford <jweather@> wrote:

Use an SIO to match the prompts and trigger sending the user/password.

On Fri, Aug 10, 2012 at 1:34 PM, maglite4cell <maglite4cell@>wrote:

**


I have a device that I can send commands to however when I connect to the
Telnet it asks for a user name and password. I was hoping to see if anyone
encountered this before and if there was an example I could work off of.

--
Jeremy Weatherford


[Non-text portions of this message have been removed]

I have a client that hates LCDs, loves plasmas. Tells me he wants one of the cheap entry level Panasonic 65" plasmas because he loves the picture. But also wants discrete input select, direct channel selection from the built in tuner and discrete power on/off - all without RS-232. Balked when I suggested the Panasonic that actually has RS-232 to be able to implement all of those features because it cost quite a bit more.

Now he has asked if there is any other control system other than Crestron that will give those features - seems to think that Crestron "needs" RS-232 and another cheap control system <URC, RTI, etc> won't need RS-232 to to do everything he wants. I'm sticking with Crestron so my other option is to find a cheaper plasma with RS-232.

Anyone use another plasma sized 60"-65" that has RS-232 support and a built-in off air tuner?

Use an SIO to match the prompts and trigger sending the user/password.

On Fri, Aug 10, 2012 at 1:34 PM, maglite4cell <maglite4cell@...>wrote:

**


I have a device that I can send commands to however when I connect to the
Telnet it asks for a user name and password. I was hoping to see if anyone
encountered this before and if there was an example I could work off of.

--
Jeremy Weatherford


[Non-text portions of this message have been removed]

The colors are on remote central from a 722 and work

Sent from my pocket computer

Unless your parsing code has delays in it that would allow the buffer to fill up, I find that using destructive functions on the buffer does not ever require the use of a clearbuffer.
Remove() and Gather() are destructive and using them to pick off the buffer has never given me trouble to where I thought I needed to use clearbuffer. They only time I've ever used clearbuffer in the past was when I didn't get destructive functions or it was really late at night and I didn't have time to figure out where bugs were so I used it as a band aide.

JP


--- In Crestron@..., Tray Schaeffer <trayschaeffer@> wrote:

With respect, I have to disagree.

1. Sizing the input buffer to match the expected string length is half of the solution for this problem and good coding practice. This is not just a hack or workaround, it is essential.
If the expected string is 300 bytes long, but the input buffer is only 255 wide, an error will be returned.
However, if the buffer is sized to 350 and the same 300 characters comes in, no error is returned. Both statements above assume that the Buffer_Input is empty when the data is received which brings me to #2.

2. Since a Buffer_Input constantly appends new data to any that was received before, it is easy to see how data that is already processed but not removed could cause the buffer to be full (or full enough that an incoming data frame wont fit completely in the remaining space) when new data arrives.
Wiping the slate clean after each complete frame of data is received is not merely a workaround, it is good practice that will improve reliability.
This is why I do not parse against the Buffer_Input directly. Instead, I make a copy of a complete data frame into a temp variable and immediately clear the Buffer_Input.
Again, clearing the input buffer is not just some sort of hack or work around, it芒鈧�鈩�s the right thing to do.

3. If, for some reason, there is an aversion to clearing buffers then use a String_Input instead. Disadvantage here is that this cannot be larger than 255 chars.
Upside is that you never have to remember to clear the input as it will clear itself each time data is received.


All of that aside, you all are right that I2P modules should not suffer from these issues.


Tray


From: Stig
Sent: Friday, August 10, 2012 6:14 AM
To: Crestron@...
Subject: [Crestron] Re: Error msg. Buffer Input overflow in S+ for Panasonic PT-AE4000U


Maybe I'm overlooking something here, but I really can't see how increasing the buffer can make the overflow msg. disappear.
A Clearbuffer can accomplish it, if it is placed right, but this is suggested only as a workaround on the real issue.

If you take a look at the code in the simpl+ module, it will Remove characters from the buffer ONLY if: Lamp_Requested is 1 AND ETX("&#92;x03") is found. ie. The buffer will still be filled up with replies from other polls!
This is excactly the same issue I experienced today with the I2P "BenQ SP920 v1.0.umc with BenQ SP920 v1.0 Processor.usp"
This module will also start Removing chr's from buffer ONLY if delimter+Lampresponse is present,
otherwise buffer get filled up to maxbufsize then gulping out overflow messages...

Had to rewrite both pollroutine + simpl+, and this really annoyes me.... (especially on a Friday afternoon. Grrr)

Back to the OP's question "What should I do?" the answer is: Rewrite both the pollroutine & the lamp hours module.

IMHO We should expect I2P modules to be better written than this.

-Stig

--- In mailto:Crestron%40yahoogroups.com, Rafael Costa <rafaelg.costa@> wrote:

Hello,
I脗麓m controlling a Panasonic projector PT-AE4000U with CresDB module
for PT-AE1000U (Panansonic Lamp Hours v1.0) and it脗麓s working fine.
Even so, I am receiving this error message -> "Error:
splusmanagerapp.exe [App 1] # 21:01:28 8-08-2012 # Module
S-5.1.1:S-2.4 : Panansonic_Lamp_Hours_v1_1 at line 136: Buffer Input
overflow. New = 260, Max = 255"
What should I do, change the "BUFFER_INPUT From_Device$[255];"
parameter to [260], is it possible?

Here is the S+ part:
LINE 44 DIGITAL_INPUT Lamp_Requested;
LINE 47 BUFFER_INPUT From_Device$[255];

LINE 133 change From_Device$
LINE 134 {
LINE 135 // Lamp hours are of the form "&#92;x02####&#92;x03"
LINE 136 if(iBusyFlag = 0 && Lamp_Requested = 1) // if not busy
processing and it is a valid lamp request
LINE 137 {
LINE 138 iBusyFlag = 1; // set busy to avoid re-entry into parser
LINE 139 while(find("&#92;x03", From_Device$) > 0 ) // look for the
ETX during a Lamp Request
LINE 140 {
LINE 141 sTemp$ = remove("&#92;x03", From_Device$); // build the
string
LINE 142 if (find ("ER401", sTemp$) = 0 && Len(sTemp$) = 6)
// Skip errors and unwanted strings
LINE 143 {
LINE 144 Lamp_Hours = ATOI(mid(sTemp$,2,4)); // set
lamp hours
LINE 145 }
LINE 146 }
LINE 147 iBusyFlag = 0; // clear busy
LINE 148 }
LINE 149 }

PMC3+ with firmware 1.005.0008 and all programs and database up to date.

Thank脗麓s in advance,
Rafael Costa

[Non-text portions of this message have been removed]

Can anyone give me a compelling reason to spend extra money on the 3-series card frame and cards when I can get the same features in a slaved CP2e? Need to add Com, IR and relays to an MC3 and a Cresnet slaved CP2e seems like a pretty solid choice for less money.

Heath

With respect, I have to disagree.

1. Sizing the input buffer to match the expected string length is half of the solution for this problem and good coding practice. This is not just a hack or workaround, it is essential.
If the expected string is 300 bytes long, but the input buffer is only 255 wide, an error will be returned.
However, if the buffer is sized to 350 and the same 300 characters comes in, no error is returned. Both statements above assume that the Buffer_Input is empty when the data is received which brings me to #2.

2. Since a Buffer_Input constantly appends new data to any that was received before, it is easy to see how data that is already processed but not removed could cause the buffer to be full (or full enough that an incoming data frame wont fit completely in the remaining space) when new data arrives.
Wiping the slate clean after each complete frame of data is received is not merely a workaround, it is good practice that will improve reliability.
This is why I do not parse against the Buffer_Input directly. Instead, I make a copy of a complete data frame into a temp variable and immediately clear the Buffer_Input.
Again, clearing the input buffer is not just some sort of hack or work around, it芒鈧�鈩�s the right thing to do.

3. If, for some reason, there is an aversion to clearing buffers then use a String_Input instead. Disadvantage here is that this cannot be larger than 255 chars.
Upside is that you never have to remember to clear the input as it will clear itself each time data is received.


All of that aside, you all are right that I2P modules should not suffer from these issues.


Tray


From: Stig
Sent: Friday, August 10, 2012 6:14 AM
To: Crestron@...
Subject: [Crestron] Re: Error msg. Buffer Input overflow in S+ for Panasonic PT-AE4000U


Maybe I'm overlooking something here, but I really can't see how increasing the buffer can make the overflow msg. disappear.
A Clearbuffer can accomplish it, if it is placed right, but this is suggested only as a workaround on the real issue.

If you take a look at the code in the simpl+ module, it will Remove characters from the buffer ONLY if: Lamp_Requested is 1 AND ETX("&#92;x03") is found. ie. The buffer will still be filled up with replies from other polls!
This is excactly the same issue I experienced today with the I2P "BenQ SP920 v1.0.umc with BenQ SP920 v1.0 Processor.usp"
This module will also start Removing chr's from buffer ONLY if delimter+Lampresponse is present,
otherwise buffer get filled up to maxbufsize then gulping out overflow messages...

Had to rewrite both pollroutine + simpl+, and this really annoyes me.... (especially on a Friday afternoon. Grrr)

Back to the OP's question "What should I do?" the answer is: Rewrite both the pollroutine & the lamp hours module.

IMHO We should expect I2P modules to be better written than this.

-Stig

--- In mailto:Crestron%40yahoogroups.com, Rafael Costa <rafaelg.costa@> wrote:

Hello,
I脗麓m controlling a Panasonic projector PT-AE4000U with CresDB module
for PT-AE1000U (Panansonic Lamp Hours v1.0) and it脗麓s working fine.
Even so, I am receiving this error message -> "Error:
splusmanagerapp.exe [App 1] # 21:01:28 8-08-2012 # Module
S-5.1.1:S-2.4 : Panansonic_Lamp_Hours_v1_1 at line 136: Buffer Input
overflow. New = 260, Max = 255"
What should I do, change the "BUFFER_INPUT From_Device$[255];"
parameter to [260], is it possible?

Here is the S+ part:
LINE 44 DIGITAL_INPUT Lamp_Requested;
LINE 47 BUFFER_INPUT From_Device$[255];

LINE 133 change From_Device$
LINE 134 {
LINE 135 // Lamp hours are of the form "&#92;x02####&#92;x03"
LINE 136 if(iBusyFlag = 0 && Lamp_Requested = 1) // if not busy
processing and it is a valid lamp request
LINE 137 {
LINE 138 iBusyFlag = 1; // set busy to avoid re-entry into parser
LINE 139 while(find("&#92;x03", From_Device$) > 0 ) // look for the
ETX during a Lamp Request
LINE 140 {
LINE 141 sTemp$ = remove("&#92;x03", From_Device$); // build the
string
LINE 142 if (find ("ER401", sTemp$) = 0 && Len(sTemp$) = 6)
// Skip errors and unwanted strings
LINE 143 {
LINE 144 Lamp_Hours = ATOI(mid(sTemp$,2,4)); // set
lamp hours
LINE 145 }
LINE 146 }
LINE 147 iBusyFlag = 0; // clear busy
LINE 148 }
LINE 149 }

PMC3+ with firmware 1.005.0008 and all programs and database up to date.

Thank脗麓s in advance,
Rafael Costa

[Non-text portions of this message have been removed]

Try ebay?

--- In Crestron@..., "sevenstarokawari" <tabata@> wrote:

Hi, I am Japanese.
In case of Japan, ST-CS is out of discontinued model due to "PSE certification"
PSE certification is, safety basis which Japanese government defines.

Anyway ST-CS doesn't have the PSE mark.
So Crestron Japan doesn't sell ST-CS to any their distributors.
Thus there is no way to buy that product. But I would like to buy still!!
Therefore I am looking for the third party current sensor which can send the current value (I hope) via RS-232C.

Is there such a product in the world?
If I can buy from this website, I am very happy.
www.smarthome.com

Regards,

With respect, I have to disagree.

1. Sizing the input buffer to match the expected string length is half of the solution for this problem and good coding practice. This is not just a hack or workaround, it is essential.
If the expected string is 300 bytes long, but the input buffer is only 255 wide, an error will be returned.
However, if the buffer is sized to 350 and the same 300 characters comes in, no error is returned. Both statements above assume that the Buffer_Input is empty when the data is received which brings me to #2.

2. Since a Buffer_Input constantly appends new data to any that was received before, it is easy to see how data that is already processed but not removed could cause the buffer to be full (or full enough that an incoming data frame wont fit completely in the remaining space) when new data arrives.
Wiping the slate clean after each complete frame of data is received is not merely a workaround, it is good practice that will improve reliability.
This is why I do not parse against the Buffer_Input directly. Instead, I make a copy of a complete data frame into a temp variable and immediately clear the Buffer_Input.
Again, clearing the input buffer is not just some sort of hack or work around, it芒鈧�鈩�s the right thing to do.

3. If, for some reason, there is an aversion to clearing buffers then use a String_Input instead. Disadvantage here is that this cannot be larger than 255 chars.
Upside is that you never have to remember to clear the input as it will clear itself each time data is received.


All of that aside, you all are right that I2P modules should not suffer from these issues.


Tray


From: Stig
Sent: Friday, August 10, 2012 6:14 AM
To: Crestron@...
Subject: [Crestron] Re: Error msg. Buffer Input overflow in S+ for Panasonic PT-AE4000U


Maybe I'm overlooking something here, but I really can't see how increasing the buffer can make the overflow msg. disappear.
A Clearbuffer can accomplish it, if it is placed right, but this is suggested only as a workaround on the real issue.

If you take a look at the code in the simpl+ module, it will Remove characters from the buffer ONLY if: Lamp_Requested is 1 AND ETX("&#92;x03") is found. ie. The buffer will still be filled up with replies from other polls!
This is excactly the same issue I experienced today with the I2P "BenQ SP920 v1.0.umc with BenQ SP920 v1.0 Processor.usp"
This module will also start Removing chr's from buffer ONLY if delimter+Lampresponse is present,
otherwise buffer get filled up to maxbufsize then gulping out overflow messages...

Had to rewrite both pollroutine + simpl+, and this really annoyes me.... (especially on a Friday afternoon. Grrr)

Back to the OP's question "What should I do?" the answer is: Rewrite both the pollroutine & the lamp hours module.

IMHO We should expect I2P modules to be better written than this.

-Stig

--- In mailto:Crestron%40yahoogroups.com, Rafael Costa <rafaelg.costa@> wrote:

Hello,
I脗麓m controlling a Panasonic projector PT-AE4000U with CresDB module
for PT-AE1000U (Panansonic Lamp Hours v1.0) and it脗麓s working fine.
Even so, I am receiving this error message -> "Error:
splusmanagerapp.exe [App 1] # 21:01:28 8-08-2012 # Module
S-5.1.1:S-2.4 : Panansonic_Lamp_Hours_v1_1 at line 136: Buffer Input
overflow. New = 260, Max = 255"
What should I do, change the "BUFFER_INPUT From_Device$[255];"
parameter to [260], is it possible?

Here is the S+ part:
LINE 44 DIGITAL_INPUT Lamp_Requested;
LINE 47 BUFFER_INPUT From_Device$[255];

LINE 133 change From_Device$
LINE 134 {
LINE 135 // Lamp hours are of the form "&#92;x02####&#92;x03"
LINE 136 if(iBusyFlag = 0 && Lamp_Requested = 1) // if not busy
processing and it is a valid lamp request
LINE 137 {
LINE 138 iBusyFlag = 1; // set busy to avoid re-entry into parser
LINE 139 while(find("&#92;x03", From_Device$) > 0 ) // look for the
ETX during a Lamp Request
LINE 140 {
LINE 141 sTemp$ = remove("&#92;x03", From_Device$); // build the
string
LINE 142 if (find ("ER401", sTemp$) = 0 && Len(sTemp$) = 6)
// Skip errors and unwanted strings
LINE 143 {
LINE 144 Lamp_Hours = ATOI(mid(sTemp$,2,4)); // set
lamp hours
LINE 145 }
LINE 146 }
LINE 147 iBusyFlag = 0; // clear busy
LINE 148 }
LINE 149 }

PMC3+ with firmware 1.005.0008 and all programs and database up to date.

Thank脗麓s in advance,
Rafael Costa

[Non-text portions of this message have been removed]

As long as you guys are comparing apples and oranges (Stig's comments
on this specific module vs. Tray's grand programming concepts), let me
throw in some bananas....

This should be done with just SIMPL. No S+ moots all the buffer
size/management arguments.

Ha!



On Fri, 10 Aug 2012 14:54:17 -0000, "Stig" <ska@...> wrote:

Ted,
I agree with you that increasing the buffer sometimes is necessary, but in
this case I don't believe that's the issue and it will not alone fix the
problem as you also need to extract from/empty the buffer one way or another.
As you say, clearing the buffer once you have received the packet and
extracted it to a tempstring is one solution but my impression is that a
well written parsing routine pour contents from the buffer to a tempstring
delimiterwise, as exemplified many times before on this forum, so there
should be no need to clear the buffer at any time ?

What upsets me is that many I2P modules from the mothership is failing, and
buffer overflow's seems to be a common issue.

-Stig

--- In Crestron@..., Tray Schaeffer <trayschaeffer@> wrote:

With respect, I have to disagree.

1. Sizing the input buffer to match the expected string length is half of
the solution for this problem and good coding practice. This is not just
a hack or workaround, it is essential.
If the expected string is 300 bytes long, but the input buffer is only
255 wide, an error will be returned.
However, if the buffer is sized to 350 and the same 300 characters comes
in, no error is returned. Both statements above assume that the
Buffer_Input is empty when the data is received which brings me to #2.

2. Since a Buffer_Input constantly appends new data to any that was
received before, it is easy to see how data that is already processed but
not removed could cause the buffer to be full (or full enough that an
incoming data frame wont fit completely in the remaining space) when new
data arrives.
Wiping the slate clean after each complete frame of data is received is
not merely a workaround, it is good practice that will improve reliability.
This is why I do not parse against the Buffer_Input directly. Instead, I
make a copy of a complete data frame into a temp variable and immediately
clear the Buffer_Input.
Again, clearing the input buffer is not just some sort of hack or work
around, it's the right thing to do.

3. If, for some reason, there is an aversion to clearing buffers then use
a String_Input instead. Disadvantage here is that this cannot be larger
than 255 chars.
Upside is that you never have to remember to clear the input as it will
clear itself each time data is received.


All of that aside, you all are right that I2P modules should not suffer
from these issues.


Tray


From: Stig
Sent: Friday, August 10, 2012 6:14 AM
To: Crestron@...
Subject: [Crestron] Re: Error msg. Buffer Input overflow in S+ for
Panasonic PT-AE4000U


Maybe I'm overlooking something here, but I really can't see how
increasing the buffer can make the overflow msg. disappear.
A Clearbuffer can accomplish it, if it is placed right, but this is
suggested only as a workaround on the real issue.

If you take a look at the code in the simpl+ module, it will Remove
characters from the buffer ONLY if: Lamp_Requested is 1 AND ETX("&#92;x03")
is found. ie. The buffer will still be filled up with replies from other
polls!
This is excactly the same issue I experienced today with the I2P "BenQ
SP920 v1.0.umc with BenQ SP920 v1.0 Processor.usp"
This module will also start Removing chr's from buffer ONLY if
delimter+Lampresponse is present,
otherwise buffer get filled up to maxbufsize then gulping out overflow
messages...

Had to rewrite both pollroutine + simpl+, and this really annoyes me....
(especially on a Friday afternoon. Grrr)

Back to the OP's question "What should I do?" the answer is: Rewrite both
the pollroutine & the lamp hours module.

IMHO We should expect I2P modules to be better written than this.

-Stig

--- In mailto:Crestron%40yahoogroups.com, Rafael Costa <rafaelg.costa@> wrote:

Hello,
I脗麓m controlling a Panasonic projector PT-AE4000U with CresDB module
for PT-AE1000U (Panansonic Lamp Hours v1.0) and it脗麓s working fine.
Even so, I am receiving this error message -> "Error:
splusmanagerapp.exe [App 1] # 21:01:28 8-08-2012 # Module
S-5.1.1:S-2.4 : Panansonic_Lamp_Hours_v1_1 at line 136: Buffer Input
overflow. New = 260, Max = 255"
What should I do, change the "BUFFER_INPUT From_Device$[255];"
parameter to [260], is it possible?

Here is the S+ part:
LINE 44 DIGITAL_INPUT Lamp_Requested;
LINE 47 BUFFER_INPUT From_Device$[255];

LINE 133 change From_Device$
LINE 134 {
LINE 135 // Lamp hours are of the form "&#92;x02####&#92;x03"
LINE 136 if(iBusyFlag = 0 && Lamp_Requested = 1) // if not busy
processing and it is a valid lamp request
LINE 137 {
LINE 138 iBusyFlag = 1; // set busy to avoid re-entry into parser
LINE 139 while(find("&#92;x03", From_Device$) > 0 ) // look for the
ETX during a Lamp Request
LINE 140 {
LINE 141 sTemp$ = remove("&#92;x03", From_Device$); // build the
string
LINE 142 if (find ("ER401", sTemp$) = 0 && Len(sTemp$) = 6)
// Skip errors and unwanted strings
LINE 143 {
LINE 144 Lamp_Hours = ATOI(mid(sTemp$,2,4)); // set
lamp hours
LINE 145 }
LINE 146 }
LINE 147 iBusyFlag = 0; // clear busy
LINE 148 }
LINE 149 }

PMC3+ with firmware 1.005.0008 and all programs and database up to date.

Thank脗麓s in advance,
Rafael Costa

Hi, I am Japanese.
In case of Japan, ST-CS is out of discontinued model due to "PSE certification"
PSE certification is, safety basis which Japanese government defines.

Anyway ST-CS doesn't have the PSE mark.
So Crestron Japan doesn't sell ST-CS to any their distributors.
Thus there is no way to buy that product. But I would like to buy still!!
Therefore I am looking for the third party current sensor which can send the current value (I hope) via RS-232C.

Is there such a product in the world?
If I can buy from this website, I am very happy.
www.smarthome.com

Regards,

Ted,
I agree with you that increasing the buffer sometimes is necessary, but in
this case I don't believe that's the issue and it will not alone fix the
problem as you also need to extract from/empty the buffer one way or another.
As you say, clearing the buffer once you have received the packet and
extracted it to a tempstring is one solution but my impression is that a
well written parsing routine pour contents from the buffer to a tempstring
delimiterwise, as exemplified many times before on this forum, so there
should be no need to clear the buffer at any time ?

What upsets me is that many I2P modules from the mothership is failing, and
buffer overflow's seems to be a common issue.

-Stig

--- In Crestron@..., Tray Schaeffer <trayschaeffer@...> wrote:

With respect, I have to disagree.

1. Sizing the input buffer to match the expected string length is half of
the solution for this problem and good coding practice. This is not just
a hack or workaround, it is essential.
If the expected string is 300 bytes long, but the input buffer is only
255 wide, an error will be returned.
However, if the buffer is sized to 350 and the same 300 characters comes
in, no error is returned. Both statements above assume that the
Buffer_Input is empty when the data is received which brings me to #2.

2. Since a Buffer_Input constantly appends new data to any that was
received before, it is easy to see how data that is already processed but
not removed could cause the buffer to be full (or full enough that an
incoming data frame wont fit completely in the remaining space) when new
data arrives.
Wiping the slate clean after each complete frame of data is received is
not merely a workaround, it is good practice that will improve reliability.
This is why I do not parse against the Buffer_Input directly. Instead, I
make a copy of a complete data frame into a temp variable and immediately
clear the Buffer_Input.
Again, clearing the input buffer is not just some sort of hack or work
around, it's the right thing to do.

3. If, for some reason, there is an aversion to clearing buffers then use
a String_Input instead. Disadvantage here is that this cannot be larger
than 255 chars.
Upside is that you never have to remember to clear the input as it will
clear itself each time data is received.


All of that aside, you all are right that I2P modules should not suffer
from these issues.


Tray


From: Stig
Sent: Friday, August 10, 2012 6:14 AM
To: Crestron@...
Subject: [Crestron] Re: Error msg. Buffer Input overflow in S+ for
Panasonic PT-AE4000U


Maybe I'm overlooking something here, but I really can't see how
increasing the buffer can make the overflow msg. disappear.
A Clearbuffer can accomplish it, if it is placed right, but this is
suggested only as a workaround on the real issue.

If you take a look at the code in the simpl+ module, it will Remove
characters from the buffer ONLY if: Lamp_Requested is 1 AND ETX("&#92;x03")
is found. ie. The buffer will still be filled up with replies from other
polls!
This is excactly the same issue I experienced today with the I2P "BenQ
SP920 v1.0.umc with BenQ SP920 v1.0 Processor.usp"
This module will also start Removing chr's from buffer ONLY if
delimter+Lampresponse is present,
otherwise buffer get filled up to maxbufsize then gulping out overflow
messages...

Had to rewrite both pollroutine + simpl+, and this really annoyes me....
(especially on a Friday afternoon. Grrr)

Back to the OP's question "What should I do?" the answer is: Rewrite both
the pollroutine & the lamp hours module.

IMHO We should expect I2P modules to be better written than this.

-Stig

--- In mailto:Crestron%40yahoogroups.com, Rafael Costa <rafaelg.costa@> wrote:

Hello,
I脗麓m controlling a Panasonic projector PT-AE4000U with CresDB module
for PT-AE1000U (Panansonic Lamp Hours v1.0) and it脗麓s working fine.
Even so, I am receiving this error message -> "Error:
splusmanagerapp.exe [App 1] # 21:01:28 8-08-2012 # Module
S-5.1.1:S-2.4 : Panansonic_Lamp_Hours_v1_1 at line 136: Buffer Input
overflow. New = 260, Max = 255"
What should I do, change the "BUFFER_INPUT From_Device$[255];"
parameter to [260], is it possible?

Here is the S+ part:
LINE 44 DIGITAL_INPUT Lamp_Requested;
LINE 47 BUFFER_INPUT From_Device$[255];

LINE 133 change From_Device$
LINE 134 {
LINE 135 // Lamp hours are of the form "&#92;x02####&#92;x03"
LINE 136 if(iBusyFlag = 0 && Lamp_Requested = 1) // if not busy
processing and it is a valid lamp request
LINE 137 {
LINE 138 iBusyFlag = 1; // set busy to avoid re-entry into parser
LINE 139 while(find("&#92;x03", From_Device$) > 0 ) // look for the
ETX during a Lamp Request
LINE 140 {
LINE 141 sTemp$ = remove("&#92;x03", From_Device$); // build the
string
LINE 142 if (find ("ER401", sTemp$) = 0 && Len(sTemp$) = 6)
// Skip errors and unwanted strings
LINE 143 {
LINE 144 Lamp_Hours = ATOI(mid(sTemp$,2,4)); // set
lamp hours
LINE 145 }
LINE 146 }
LINE 147 iBusyFlag = 0; // clear busy
LINE 148 }
LINE 149 }

PMC3+ with firmware 1.005.0008 and all programs and database up to date.

Thank脗麓s in advance,
Rafael Costa