PINK Server: Refresh web screen causes Stamp Program to reinitialize

xanatos

I am running a BS2SX hooked up to a PINK server.· The stamp repeatedly scans a set of variables in the PINK that are set by the web page I've put into it (scanning NBVars 51-62 with SEROUT/SERIN commands, approximately one scan of the 12 variables every 2 seconds).· This all works perfectly, and when the data it is looking for appears, it operates on it perfectly.

What I noticed just now however is that if the web screen is refreshed - either manually or via a META REFRESH tag (the data on the screen deos need to be refreshed as the value of some variables is changed dynamically by the stamp) - the stamp program is reinitialized!

This currently does not seem to pose any really horrible consequences, but I am concerned that it may later on down the road with this project.

Is this normal behavior for the PINK?· Does anyone know what the mechanism is that triggers the system to reinitialize the stamp program on a web screen refresh?· If it is the result of the SERIN or SEROUT command being chopped off in mid sentence by a random refresh, is there a programattic solution to allow the program to NOT reinitialize?· I DO have timeout routines built in to all of my SERINs - do I need them on my SEROUTs as well?· ANd would an aborted serial communication be applicable to a timeout routine, or is there a separate way to handle that?

These are the only points of interaction I can think of between the stamp's program and the PINK...

I will eventually be having data at the front of the program that will set some initial values, and it would be an issue at that time to have those values reloading every time the page refreshes.....

Thanks for any insight.· I don't recall seeing ANYTHING about this in any of the PINK manuals...

Dave


·

Mike Green

There is no way for the PINK to reinitialize the Stamp other than a power shortage causing the Stamp to reset or a programming error on the Stamp that causes a stack underflow (RETURN without a matching GOSUB) which can cause a Stamp reset. If you haven't tested all the timeouts, that could be one way that something on the PINK could cause a reset. If the timeout GOTO causes an extra RETURN by mistake, that would explain what happens.

Chris Savage

Hello,

I’m with Mike…nothing the PINK can do will cause the BASIC Stamp to reset short of a power issue. I helped define the PINK Firmware so I know how it works and here is my best guess at what is happening based on the information you have provided. Before I reply though, let me say that typically if you’re waiting for information on the PINK to change you would simply monitor the flag register and take action if/when the appropriate flag was set/cleared.

It sounds like you’re actually reading the variables on the fly and comparing them to see if they have changed. This is not how the PINK firmware was designed and this would take considerable time. Not only that, but depending on how you’re handling time-outs it could be possible that a SERIN command is being delayed and timing out during a web page refresh.

If you’re trying to detect when a variable has changed you should have a look at the example code, “PINKTestStatusV1.0.BS2”. This code monitors the status register within a loop and displays a message for anything updated and the variable that was updated. It does this by first sending a command to the PINK Module:

SEROUT TX, Baud, [noparse][[/noparse]"!NB0ST"] ' Command To Read Status Reg

At this point it sends a command to read the result:

SERIN RX, Baud, 750, Timeout, [noparse][[/noparse]status]' Get Status Byte With Timeout

At this point the individual bits are checked to see if any of the flags changed indicating a changed variable or incoming UDP message.

Notice the timeout? If the PINK does not respond this is handled in this example by displaying an error and terminating the program. It could however have been handled in a more sophisticated program by retrying the command more times and then taking additional action and/or terminating communication with the hardware for being unresponsive. A colleague of mine recently informed me of a problem he was having with initialization of a piece of hardware so his program actually shuts off power to the device and then turns it on again to ‘reset’ things. This seems to work for him.

The point is that you need to handle such issues as a delay or lack of a response from the device so your program doesn’t hang or become erratic. Also note that reading this single byte from the PINK module is much more efficient than reading an entire group of variables looking for a change. I hope this helps. Take care.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering

xanatos

This is good info. The only variable I was reading on the fly is a flag I had set up manually, so the pink is being polled periodically looking for a 1 or a 0 on that single variable. When it sees that variable change to a 1, it then reads three other variables and goes to a subroutine that reads a few more and resets the original variable back to 0. This is done because variables are updated on the pink by JavaScript on the web page, but those variables do not need to be read in when they change, only when the flag variable changes to 1. I do have timeouts running on all of my serins, most of which simply pause 100ms and retry with incremental counts before generating an error message.... But they never get far enough in the count to generate that message, 2 is the highestcount I've seen yet.

Maybe I've mis-stated when I say the system causes the stamp to reinitialize; I only refer to it as such because there are a group of variables I set manually in the stamp code that are physically positioned earlier in the program before "Main:", and once the program is started, all gosubs end in either a return or a goto main, so I am trying to figure out what might send the program back to the starting point.

As for power issues, I am running the system with a Mean Well SD-15B-05 5v 3A power supply, which only needs to power the stamp, pink, ds1302 and an XBee XSC, so I see no current issues there, and I observe no flickering LEDs, etc.

So I am polling the pink for only one variable, and only reading the rest when it sees that one variable has changed. I'm sure it's a coding issue related to the timeout for the serin, as it only happens infrequently when the web page is refreshed and the stamp is polling for the flag change, but the timeout subroutine ends in a return, yet the program is sent back to the beginning... It's almost like the abort of a serin (as opposed to a timeout) makes the program forget where "return" is and it just sends it back to start.

Is there any difference as far as the stamp is concerned between a serin timing out, vs a serin being aborted in mid sentence, so to speak?

Thanks,

Dave

Mike Green

There is no difference between a SERIN timing out vs a SERIN being aborted in mid sentence. The only way to abort a SERIN is to have a timeout and the timeout works just like a GOTO.

You mentioned a timeout routine that ends with a RETURN. That could be your problem. The timeout routine is given control with a GOTO, not a GOSUB.

Post Edited (Mike Green) : 7/2/2009 2:43:35 PM GMT

Chris Savage

You also mentioned that all GOSUB end in either RETURN or GOTO Main, the latter of which can cause the same problem Mike mentioned earlier.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering

xanatos

OK... maybe that's wher it is. Here's some code. First, this is the bit flag I change when the data is actually ready to be read:

SEROUT TX, Baud, [noparse][[/noparse]"!NB0R33"] ' Send Command To Read Variable 33 on PINK ("something's changed" bit)
SERIN RX, Baud, 100, Timeout, [noparse][[/noparse]dflag] ' Get data changed variable value

Note the Timeout in the SERIN command. Here is the code for Timeout:

Timeout:
DEBUG "Server busy, Stand by...", CR ' Serial Timeout - usually when server is being written to from web page.
PAUSE 1000
RETURN

Are you saying that this subroutine should end in a GOTO rather than a RETURN? I could insert a "Resume:" label and put a GOTO Resume statement in place fo the RETURN... is this what you are referring to? And if so, what is it that I am not understanding about gosubs? I thought RETURN was supposed to return the program to the very next line following the initial GOSUB statement...???

Thanks!

Dave

Chris Savage

That is correct...you are executing a RETURN without GOSUB. This can cause the BASIC Stamp to 'restart' causing it to run the code as if it were reset.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering

xanatos

Ahhhhhhhhh.....· !!!!!!· Enlightenment!· I sort of thought the Timeout call in the SERIN *was* treated as a GOSUB.... hence the issue.· I believe that's exactly what is happening, and when I get back into the code later this evening, I'll let you know!

Thank you!!!

Dave

PS., Since you helped design the firmware for the PINK, I just wanted to say THANK YOU!· That little item has made so many cool applications possible for me, and for my clients, who will be ordering MANY more of these very shortly!

The only thing that could make the PINK cooler would be if there were a way to write to the flash variables from a user-created web page, resulting in nonvolatile data storage for the attached microcontroller... :-)·

If you're interested, I've attached a photo of the PINK in the final prototype board.· There's a Parallax USB datalogger sandwiched under the pink, along with a few other components.

Chris Savage

Well if your problems are solved then I am just happy to see that. Nice setup. You've got a lot of hardware under the hood there. Take care.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering

xanatos

It appears that that was indeed it! I have not seen the issue recurr since I inserted a label after the SERIN and replaced the RETURN with a GOTO label, and I have tested it with a meta refresh tag set to 5 seconds, and let it run for about 5 minutes - no problem!

Thanks again!!

Dave

PS., I'm curious if anyone has any better ideas about how to synchronize the ds1302's time with the computer's time (that is hooked up via the PINK cat-5) other than what I'm doing - I have a javascript routine that - when a form button is submitted - writes the values for year, month, date, hour, etc... to hidden inputs that are NB_Vars, and sets the data changed flag to a value that is read by the controller, and tells the controller to gosub to the time_set routine, where it reads those NB_Vars and sends them into the ds1302. It works like a charm and I have integrated it into the rest of my program seamlessly... but I'm just wondering if there isn't a more efficient solution?

Chris Savage

Actually that’s a pretty clever method of grabbing the time. I would be interested in seeing the code for that if it is available. The closest I have been to worrying about getting the time from a PC was from a client in NY who did not want to share any information about his application with me. He hired me to simply demonstrate how I would get the time from the PC into the DS1302. I used the serial connection already provided for programming and wrote a TSR on the PC (yes, DOS) that sent the date/time out the PC serial port whenever it received a certain series of bytes on the same port. The BASIC Stamp would request the new time at (usually) midnight and adjust the DS1302 accordingly. He seemed happy with it, through I never heard from him again.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering

xanatos

Hi chris,
I'm travelling in Maine right now, but I'll be happy to share the selected parts with you when I get back. My complete code I need to keep close to the vest, but the time sync part I can share. I just did what made sense... basically I have a JavaScript clock running on the "console" - which means the web page I have dropped onto the PINK. This clock updates the screen every second by writing to the html SPAN ID that contains it. I added a line of code that, when the "sync time" button is clicked, also sets the "document.formname.inputname.value" of several hidden inputs to be equal to the YY, MM, DD, HH, MM and SS that the clock is writing to the screen at that instant. I also add 5 seconds to the SS time to account for the delay from the time the butotn is pressed until the time is actually updated and debug'd out to the terminal window. The form also sets my flag variable to 1, and when the BS2sx sees that, it grabs the variables and reads them into the DS1302. This is why I have my own flag variables set up, as just reading the status register alone would cause too many unnecessary reads of the PINK. By having multiple values set to the flag variable, I can instruct the BS2sx what particular function to execute so only the pertinent variables are read. I'm writing to the PINK Vars far more frequently than I need to actually read, as some of the PINK vars are used to do stuff on the operator's console window that make it act more like a server-side application than ust a static web page.

I can't tell you enough how much I love the PINK! The possibilities I have been able to make real with this item have made me very happy, and made my clients ecstatic!

I'll forward the code to you in a PM when I get back.

Dave

Chris Savage

Dave,

Thanks for your thoughts, comments and code. Take care.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering

xanatos

Hi Chris,

You have a PM with code to sync time from the web page into the DS1302, and to read PINK vars directly into JavaScript for whatever purpose you need. Looking forward to your thoughts.

Dave X

Chris Savage

Thank you...hopefully I will get to work on that this weekend. Take care.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering