Code with terminal instruction requires small delay after download

[VonSzarvas]

In this simple example, taken from the learn website (ie. lot's of customer will start with this!)....

There is no pause in the learn example, and the call to Terminal appears to fail most times. Adding the pause resolves.

I think it's fairly clear what the issue can be :)

In terms of improving reliability, how about auto-adding a ~1000ms pause at the start of "main" for any code that includes terminal routines ?

If that's not possible, I think the learn site needs updating pronto, at all pages that have example code including Terminal blocks.

Additional - This could apply to blockly.parallax.com too... not tried it over there.

[PropGit]

@VonSzarvas - I have some questions:

• In what way does it fail?
  • No terminal appears?
  • No "Hello World!" on terminal?
• Any difference in the connect message?
• What OS+Browser are you using?
• BP Client or BP Launcher?

[VonSzarvas]

download ok, terminal windows appears with correct baud/com details shown in the title bar however, terminal window remains blank / black.

connect msg - no differences noticed.

Win10 Home with Chrome OS78

BP Client and solo.parallax.com

(This was tested on my PC in response to #433. He has similar specs I think. The pause solved things for me, but not the customer. Sure I could try some other configurations/computers tomorrow if this is a new thing that needs testing)

[PropGit]

@VonSzarvas - Okay. This seems to be an elusive problem still; I've seen it a number of times but haven't figured out any one thing that causes it.

Please retest tomorrow (or next convenient time) with the same setup, then close BlocklyProp Client and install BlocklyProp Launcher for Windows and retest with that instead.

EDIT: Keep in mind that for the moment, the top button doesn't work (until Solo gets it's secure connection enabled) but you can ignore the buttons and just navigate your browser to the site directly and BlocklyProp Launcher will work with it.

[pjewald]

Let's document that we need a delay while we test this against the BlocklyProp Launcher/Secure Solo combination. If the delay is still required in that combination, we will need to address it.

Solo now supports HTTPS but the compiler is unreachable in that configuration. That's another issue we need to solve before work continues on this issue.

[VonSzarvas]

Test results-

Tried same setup as yesterday with FLiP and PAB-WX. Both are OK now, without the pause. Oddness. ?Unless something changed overnight, that suggests that Windows might present some intermittent behaviour/timing around the USB ports.

Closed BP-Client, Installed and run the launcher. Works ok without the pause also.

However, one observation....

The Launcher cannot find the right com port, and instead seems to default to the last in the scan list (which is not an FTDI device). Manually need to dropdown/select the correct com port.

Whereas BP_Client finds the FTDI/Propeller device no problem and auto-selects the correct com port.

[VonSzarvas]

Edge test - Terminal always fails to receive data ( black empty panel). Edge Console has this familiar error : SCRIPT12017: SCRIPT12017: WebSocket Error: SECURITY_ERR, Cross zone connection not allowed

Not a concern for this incident, as I should be using Chrome... but just noting it whilst testing.

[VonSzarvas]

Summary - I think this could be closed as non-issue for now.

If I find the same problem on the Windows+Chrome combination in the future, I'll grab debug messages and re-open the topic. But for now, I think it's safe to assume the USB ports were misbehaving at a lower level (perhaps other or prior code that was running had an impact), and a reboot of the PC would likely have reset things. Seemingly not a Parallax issue.

[zfi]

I am really interested in the edge test results. The web socket error concerning the cross-zone connection should not be happening. Full stop. I need to understand if this is really CORS implemented on web sockets (probably no) or something else.

The launcher behavior should be a separate issue that needs to addressed. It should work more intuitively. We just have to figure out which end is causing all the fuss.

[VonSzarvas]

Could it be related to the URL used to access the site?

ie. solo.parallax.com or blocklyprop.com or blockly.parallax.com etc...

Perhaps the cross-zone occurs when the url doesn't match whatever js calls...

If you'd like anything tested (and more extensive debug logs grabbed) let me know. But I think you could run Edge on your own Windows PC and experience the same (At least, I hope it's not just me :)

[MatzElectronics]

I believe that by "edge", Michael is referring to the Microsoft Edge browser, which we have never supported, and the behavior described is consistent with what I have observed with that browser.

On Tue, Dec 17, 2019, 1:30 AM Michael notifications@github.com wrote:

Could it be related to the URL used to access the site?

ie. solo.parallax.com or blocklyprop.com or blockly.parallax.com etc...

Perhaps the cross-zone occurs when the url doesn't match whatever js calls...

If you'd like anything tested (and more extensive debug logs grabbed) let me know. But I think you could run Edge on your own Windows PC and experience the same (At least, I hope it's not just me :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/parallaxinc/solo/issues/201?email_source=notifications&email_token=AEWSVOBAUXXUBEGR4E2CM5TQZCL3DA5CNFSM4J3HAWY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHBXVRI#issuecomment-566459077, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEWSVOBQIXAXJ2CCOHNOEKLQZCL3DANCNFSM4J3HAWYQ .

[VonSzarvas]

Yes, I meant MS Edge. Thanks for spotting that Matt.

[PropGit]

@VonSzarvas - Is the version of Edge you are using the Chromium-based version, or the original non-Chromium-based version? You probably don't know, and I haven't checked if they've actually released the Chromium version yet.

[PropGit]

Here's our answer: Jan 15th, this all may change for the better: https://www.google.com/search?q=edge+chromium+release+date&oq=Edge+Chrom&aqs=chrome.3.0j69i57j0l4.4016j0j7&sourceid=chrome&ie=UTF-8

[PropGit]

Regarding this:

The Launcher cannot find the right com port, and instead seems to default to the last in the scan list (which is not an FTDI device). Manually need to dropdown/select the correct com port.

Whereas BP_Client finds the FTDI/Propeller device no problem and auto-selects the correct com port.

Neither the BP Client nor the BP Launcher check to see if a Propeller is on any given port until it tries to download to it. The reason they behave differently is because they provide the list of ports differently to the browser (something I have logged an issue already to enhance)... can't remember the details at the moment, but it may be that the BP Client is returning an unordered list (which is provided a the whim of the OS) and the BP Launcher is alphanumerically sorting them. Regardless, my intention is to improve BP Launcher to more intelligently handle the list that's provided to the browser based on state history and connection/disconnection events (ie: if a user had selected and used a port, that port is known-good and should be provided as the first item in the list (next time it appears, should it have been disconnected during the session). There's also a new port appearance event case that should factor in, all the lessen the need for user involvement.)

[PropGit]

Let's leave this issue open until we have proof that a delay is truly needed (or not) and resolves it in all known cases. I've haven't personally seen the delay fix the problem totally. It seems there's a system-lag problem involved here which means the delay may work in some cases and fail to resolve it in others.

[zfi]

Any further data points on this issue?

[VonSzarvas]

I've not had occasion to try this since, not any other customer requests for help on the original topic issue (small delay).

My hunch is that a small delay would help make edge-cases more reliable; when the terminal (for whatever reason) is a tad slower to grab the port and open the debug window than the Propeller starting to transmit "debug" data. And that a 1 second delay is unlikely to be noticed for applications using terminal.

But it might also be that the latest Launcher gets the right side of this intermittent issue.

As we don't have solid data, and this is non-critical, I'd vote to close this issue at this time, and if we get future reports this thread could be referred to again. (ie. focus on other solid priorities for now).