I'm using SC to communicate with a Windows program running on the same PC as SC. There are two USB ports with USB->RS232 adapters and the two adapters are connected by a physical NULL Modem.
The SC script attached, responds to requests sent out by the Windows program. The commands can be anywhere from 1 to >20 characters. The responses can be anywhere from 1 to 1024+13 characters.
The request->responses are fixed. The code compares the request to a set of known requests and each of
those requests has a fixed response.
The script is basically "if" statements in two forms:
if(string=="AAAAA"){
scriptThread.sendString("BBBBBB");return;}
if(string=="123456"){
scriptThread.sendString("56789");}elseif(string=="111111"){
scriptThread.sendString("222222[[...up to 1024+13 characters]]");}elseif.....
The handshake gets through all of the shorter requests. Then there is a sequence where there can be up to 2048 of the long (1024+13) character packets sent as a response to a request..
After responding correctly for a variable number of these long requests, V6.04 of SC just winks out... that is, it's windows close (main and Script) with no error message - just gone. When I try the same script with V5.10 of SC, I do get an error message "RangeError:Maximum call stack exceeded".
There is no recursion in my script, though I don't know what is going on in scriptThread.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2023-10-06
I can add that when SC 5.10 gets the RangeError, the error message window pops up 32 times and I must click on the [OK] button 32 times. And now I see that 32 of the long(1024+13) responses were generated when the RangeError occured.
Mark
markd@silogic.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
can you remove all scriptThread.sleepFromScript and test what happens?
If this does not help you can try to use only one call to scriptThread.sendString with the complete string.
Last edit: Stefan Zieker 2023-10-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried your script. I got the same error as you described (I used R000000000200\r\n). I changed the multiple calls to scriptThread.sendString to a single call with the complete string and the error was gone (every call adds an event to the internal event queue).
Last edit: Stefan Zieker 2023-10-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2023-10-09
Thank you, Stefan.
I found that changing the calls to sendString() to a single call did not make a difference here. v6.04 winked out after about 5 minutes.
I did find that removing almost all of the calls to sleepFromScript() made a big difference. I had to leave one call in the dataReceived() function as required by the protocol I am trying to mimic. The script has been running for almost an hour without crashing SC.
The error that I got "RangeError:Maximum call stack exceeded" seems to be related to recursive calls gone wild. I don't see how the number of non-recursive calls themselves causes this error. Right now the script has called sendString() 88,675 times and counting.
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2023-10-09
Digging a little more, I see that the call to sleepFromScript() sometimes never returns to my code.
In particular, I see this at line 186 of the updated script attached. If I comment out line 186, the script correctly prints the "10" to the console and increments packetcount by 34.
If I remove the comment, the "10" is never displayed and packetcount is not incremented.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2023-10-09
Stefan, the same thing happens with the call to sleepFromScript() at line 111 using the "R000000000200\r\n". I'm going to remove all of the calls to sleepFromScript() from my code if I can find an alternative.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
how often is the function dataReceived called? Maybe it is called faster then the code inside can be executed (if ScriptCommunicator recieves data an event is generared internally, if the script is idle then dataReceived is called if not then it is stored). Can you add a global counter which increases at the begining of dataReceived, decreases at the end of dataReceived and then be printed to the console?
Last edit: Stefan Zieker 2023-10-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2023-10-09
Stefan,
I replaced the sleepFrom Script() and sleep() calls with this that If found on StackOverflow:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2023-10-09
Stefan,
It is possible that dataReceived() is called again before it has exited. This function has to send a very large amount of information over a fairly slow serial port. With dataReceived() never exiting and never clearing the stack, each time it is called, more is left on the stack and the stack grows uncontrolled eventually exceeding the maximum stack size. This effectively looks like recursion gone wild.
But I don't understand why changing the call to sleepFromScript() to the pausit() function shown above makes the script execute correctly.
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I want to test something. Can you run your script with the attached ScriptComunicator (I changed sleepFromScript)?
Note: It runs only with the 6.4 Libraries.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2023-10-10
I downloaded your new .exe file and named it "ScriptCommunicator Special from Stefan.exe". Put it in the 6.4 folder.
First I took my script "TIU Emulator - Copy for GitHub Bug Report.js" which was the first failing script that I uploaded. I ran it with the original SC 6.4 to confirm that it fails. This script calls "sleepFromScript(100);"
It did. After about 5 minutes, the SC window just "winked out".
Then I took the same script and ran it with the new 6.5 (?). With this version of SC, the Windows program on the other end gets all sorts of data format errors. The script won't run for more than 30 seconds.
I think this exhibits some mistakes I had in the handshake performed by this original, old script.
So as another test, I took my latest version of the script which I have working using the "pauseit(100);" call instead of "sleepFromScript(100);". It runs with SC 6.4 and SC 6.5.
Then I changed the calls to "pauseit(100);" to be calls to "sleepFromScript(100);". it runs with SC 6.4 and SC 6.5
This makes me think that the underlying problem is not the sleepFromScript() call. My older scripts did not have the handshake right with the Windows program and I believe the Windows program was resending commands causing the dataReceived() to not have enough time to complete. It was aborted 3/4 of the way through leaving data on the stack which eventually
grew to maximum size as call after call was aborted.
Can't prove it either way.
It would be helpful if you could figure out a way to have SC 6.x put up an error message like SC 5.10 did.
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm using SC to communicate with a Windows program running on the same PC as SC. There are two USB ports with USB->RS232 adapters and the two adapters are connected by a physical NULL Modem.
The SC script attached, responds to requests sent out by the Windows program. The commands can be anywhere from 1 to >20 characters. The responses can be anywhere from 1 to 1024+13 characters.
The request->responses are fixed. The code compares the request to a set of known requests and each of
those requests has a fixed response.
The script is basically "if" statements in two forms:
The handshake gets through all of the shorter requests. Then there is a sequence where there can be up to 2048 of the long (1024+13) character packets sent as a response to a request..
After responding correctly for a variable number of these long requests, V6.04 of SC just winks out... that is, it's windows close (main and Script) with no error message - just gone. When I try the same script with V5.10 of SC, I do get an error message "RangeError:Maximum call stack exceeded".
There is no recursion in my script, though I don't know what is going on in scriptThread.
I hope I am clear enough in my post.
I can add that when SC 5.10 gets the RangeError, the error message window pops up 32 times and I must click on the [OK] button 32 times. And now I see that 32 of the long(1024+13) responses were generated when the RangeError occured.
Mark
markd@silogic.com
Hi Mark,
can you remove all scriptThread.sleepFromScript and test what happens?
If this does not help you can try to use only one call to scriptThread.sendString with the complete string.
Last edit: Stefan Zieker 2023-10-08
I tried your script. I got the same error as you described (I used R000000000200\r\n). I changed the multiple calls to scriptThread.sendString to a single call with the complete string and the error was gone (every call adds an event to the internal event queue).
Last edit: Stefan Zieker 2023-10-08
Thank you, Stefan.
I found that changing the calls to sendString() to a single call did not make a difference here. v6.04 winked out after about 5 minutes.
I did find that removing almost all of the calls to sleepFromScript() made a big difference. I had to leave one call in the dataReceived() function as required by the protocol I am trying to mimic. The script has been running for almost an hour without crashing SC.
The error that I got "RangeError:Maximum call stack exceeded" seems to be related to recursive calls gone wild. I don't see how the number of non-recursive calls themselves causes this error. Right now the script has called sendString() 88,675 times and counting.
Mark
Digging a little more, I see that the call to sleepFromScript() sometimes never returns to my code.
In particular, I see this at line 186 of the updated script attached. If I comment out line 186, the script correctly prints the "10" to the console and increments packetcount by 34.
If I remove the comment, the "10" is never displayed and packetcount is not incremented.
Stefan,
I'm sorry ! I uploaded the wrong script in the previous post.
I'm not sure if the console window transcript was attached to the last post. I'll include it here.
Stefan, the same thing happens with the call to sleepFromScript() at line 111 using the "R000000000200\r\n". I'm going to remove all of the calls to sleepFromScript() from my code if I can find an alternative.
Might this be related?
https://stackoverflow.com/questions/71588045/javascript-async-sleep-function-somehow-leads-to-silent-exiting-of-program
Mark
no I don't think so
Hi Mark,
how often is the function dataReceived called? Maybe it is called faster then the code inside can be executed (if ScriptCommunicator recieves data an event is generared internally, if the script is idle then dataReceived is called if not then it is stored). Can you add a global counter which increases at the begining of dataReceived, decreases at the end of dataReceived and then be printed to the console?
Last edit: Stefan Zieker 2023-10-09
Stefan,
I replaced the sleepFrom Script() and sleep() calls with this that If found on StackOverflow:
The script seems to run normally now.
Stefan,
It is possible that dataReceived() is called again before it has exited. This function has to send a very large amount of information over a fairly slow serial port. With dataReceived() never exiting and never clearing the stack, each time it is called, more is left on the stack and the stack grows uncontrolled eventually exceeding the maximum stack size. This effectively looks like recursion gone wild.
But I don't understand why changing the call to sleepFromScript() to the pausit() function shown above makes the script execute correctly.
Mark
Hi Mark,
I want to test something. Can you run your script with the attached ScriptComunicator (I changed sleepFromScript)?
Note: It runs only with the 6.4 Libraries.
Last edit: Stefan Zieker 2023-10-09
I downloaded your new .exe file and named it "ScriptCommunicator Special from Stefan.exe". Put it in the 6.4 folder.
First I took my script "TIU Emulator - Copy for GitHub Bug Report.js" which was the first failing script that I uploaded. I ran it with the original SC 6.4 to confirm that it fails. This script calls "sleepFromScript(100);"
It did. After about 5 minutes, the SC window just "winked out".
Then I took the same script and ran it with the new 6.5 (?). With this version of SC, the Windows program on the other end gets all sorts of data format errors. The script won't run for more than 30 seconds.
I think this exhibits some mistakes I had in the handshake performed by this original, old script.
So as another test, I took my latest version of the script which I have working using the "pauseit(100);" call instead of "sleepFromScript(100);". It runs with SC 6.4 and SC 6.5.
Then I changed the calls to "pauseit(100);" to be calls to "sleepFromScript(100);". it runs with SC 6.4 and SC 6.5
This makes me think that the underlying problem is not the sleepFromScript() call. My older scripts did not have the handshake right with the Windows program and I believe the Windows program was resending commands causing the dataReceived() to not have enough time to complete. It was aborted 3/4 of the way through leaving data on the stack which eventually
grew to maximum size as call after call was aborted.
Can't prove it either way.
It would be helpful if you could figure out a way to have SC 6.x put up an error message like SC 5.10 did.
Mark
Hi Mark,
I will put it on my list.
Thanks very much for all the help. What I've got now is working very well. SC lets me do testing not possible without it.
:-)