Refreshing page while connected creates a problem if you want to reconnect.
Cinezaster opened this issue · 13 comments
We need to prevent refresh page if isconnected
I have noticed that too. Chillipeppr can reconnect to spjs, so it must be
possible (:
On 7 Apr 2016 10:38, "Cinezaster" notifications@github.com wrote:
We need to prevent refresh page if isconnected
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#19
https://github.com/chilipeppr/widget-spjs/blob/master/widget.js#L2197 handles their click event:
and https://github.com/chilipeppr/widget-spjs/blob/master/widget.js#L1178 handles the port open.
We do the same so its not in the sending part... Which means it must be in https://github.com/openhardwarecoza/LaserWeb2/blob/gh-pages/js/spjs.js#L600, or we arent getting https://github.com/openhardwarecoza/LaserWeb2/blob/gh-pages/js/spjs.js#L165 back from spjs because its already open...
That's all front-end JavaScript code that solves Chilipeppr reconnecting. SPJS is ambivalent. Why don't you guys just do this as a Chilipeppr workspace and then you'd inherit all the amazingness from CP?
@johnlauer :-D good point.
Using chilipeppr for a while now on my cnc. And on my little laser engraver. I love it. You did an amazing job creating it and maintaining it.
I tried to get familiar with the code, being a big application with mixed functional code and dom manipulation it took me to long for my limited time to improve or add a piece. Also, not having my code running on a local machine as CP is in jsfiddles, I gave up.
The code structure of LaserWeb and LaserWeb2 faces the same problem as CP.
- UI code is mixed with functional code.
- Functional code is not tested.
Maintaining, building projects like this and keeping them alive by one person is hard. And in that matter we should join forces together. I'm pretty sure Peter wouldn't mind to have his gcode generators for laser engraving and cutting implemented in CP. But I guess from his perspective he chose the easy way, to build it himself and learn javascript on the job.
If people are not comfortable in a codebase, it's sometimes easier to synthesize there own version of it. I'll see this behaviour often with my own employees when they deal with bigger projects they need to alter, or when they should or could reused other code.
Splitting big codebases into functional modules with descriptive api's like most of the npm modules, can make things easier.
In this case I can image we could build an npm module with a clear api that handles everything, that has to do with the listing, connecting, disconnecting, resume connection, messaging and ... with serial port json websocket server.
Only functional, no UI manipulation. You can subscribe to events for manipulating you UI.
This module can be tested. That way the fear of breaking stuff is minimized. It makes it a lot more reusable, and less cumbersome to try to make your own version of it.
By no means this is meant as criticism. I like the hard work of everyone involved in these open source cnc'ing projects.
I sent a pull on the cp 3D viewer for the laser intensity a while back (;
and started work on a few widgets. Check my repository tab.
I have no problem porting them eventually but LaserWebs main goal is
'offline'. I dont have internet in my garage (;
Cinezaster is 100% correct though. Its easier coding from scratch, than
integration into cp. John knows how many times i bugged him with stupid
questions already (;
On 7 Apr 2016 19:22, "Cinezaster" notifications@github.com wrote:
@johnlauer https://github.com/johnlauer :-D good point.
Using chilipeppr for a while now on my cnc. And on my little laser
engraver. I love it. You did an amazing job creating it and maintaining it.
I tried to get familiar with the code, being a big application with mixed
functional code and dom manipulation it took me to long for my limited time
to improve or add a piece. Also, not having my code running on a local
machine as CP is in jsfiddles, I gave up.
The code structure of LaserWeb and LaserWeb2 faces the same problem as CP.
- UI code is mixed with functional code.
- Functional code is not tested. Maintaining, building projects like
this and keeping them alive by one person is hard. And in that matter we
should join forces together. I'm pretty sure Peter wouldn't mind to have
his gcode generators for laser engraving and cutting implemented in CP. But
I guess from his perspective he chose the easy way, to build it himself and
learn javascript on the job.If people are not comfortable in a codebase, it's sometimes easier to
synthesize there own version of it. I'll see this behaviour often with my
own employees when they deal with bigger projects they need to alter, or
when they should or could reused other code.Splitting big codebases into functional modules with descriptive api's
like most of the npm modules, can make things easier.In this case I can image we could build an npm module with a clear api
that handles everything, that has to do with the listing, connecting,
disconnecting, resume connection, messaging and ... with serial port json
websocket server.
Only functional, no UI manipulation. You can subscribe to events for
manipulating you UI.
This module can be tested. That way the fear of breaking stuff is
minimized. It makes it a lot more reusable, and less cumbersome to try to
make your own version of it.By no means this is meant as criticism. I like the hard work of everyone
involved in these open source cnc'ing projects.—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#19 (comment)
A lot of LaserWeb2 contains John's code anyway (3d viewer, svg (and my
addition of dxf) to gcode, etc
On 7 Apr 2016 19:26, "Peter van der Walt (Gmail)" peter.plaaswerf@gmail.com
wrote:
I sent a pull on the cp 3D viewer for the laser intensity a while back (;
and started work on a few widgets. Check my repository tab.I have no problem porting them eventually but LaserWebs main goal is
'offline'. I dont have internet in my garage (;Cinezaster is 100% correct though. Its easier coding from scratch, than
integration into cp. John knows how many times i bugged him with stupid
questions already (;
On 7 Apr 2016 19:22, "Cinezaster" notifications@github.com wrote:@johnlauer https://github.com/johnlauer :-D good point.
Using chilipeppr for a while now on my cnc. And on my little laser
engraver. I love it. You did an amazing job creating it and maintaining it.
I tried to get familiar with the code, being a big application with mixed
functional code and dom manipulation it took me to long for my limited time
to improve or add a piece. Also, not having my code running on a local
machine as CP is in jsfiddles, I gave up.
The code structure of LaserWeb and LaserWeb2 faces the same problem as
CP.
- UI code is mixed with functional code.
- Functional code is not tested. Maintaining, building projects like
this and keeping them alive by one person is hard. And in that matter we
should join forces together. I'm pretty sure Peter wouldn't mind to have
his gcode generators for laser engraving and cutting implemented in CP. But
I guess from his perspective he chose the easy way, to build it himself and
learn javascript on the job.If people are not comfortable in a codebase, it's sometimes easier to
synthesize there own version of it. I'll see this behaviour often with my
own employees when they deal with bigger projects they need to alter, or
when they should or could reused other code.Splitting big codebases into functional modules with descriptive api's
like most of the npm modules, can make things easier.In this case I can image we could build an npm module with a clear api
that handles everything, that has to do with the listing, connecting,
disconnecting, resume connection, messaging and ... with serial port json
websocket server.
Only functional, no UI manipulation. You can subscribe to events for
manipulating you UI.
This module can be tested. That way the fear of breaking stuff is
minimized. It makes it a lot more reusable, and less cumbersome to try to
make your own version of it.By no means this is meant as criticism. I like the hard work of everyone
involved in these open source cnc'ing projects.—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#19 (comment)
I would say your deception is spot on and the way ChiliPeppr is organized. It's all in github now and each module self documents. Even the fact that each module has an upper right corner triangle menu with a link to the code was a key decision in helping folks understand the structure.
Each module can run on it's own in the development environment so that testing is easy.
Modules communicate over a standard and documented pub sub interface for each module. This has been key for ChiliPeppr to grow.
Lastly I've made a lot of videos to walk people through it.
I agree with you we all want to write from scratch but that almost makes any large project get worse. So anyway we cut this it is hard to solve.
On Thu, Apr 7, 2016 at 10:22 AM -0700, "Cinezaster" <notifications@github.commailto:notifications@github.com> wrote:
@johnlauerhttps://github.com/johnlauer :-D good point.
Using chilipeppr for a while now on my cnc. And on my little laser engraver. I love it. You did an amazing job creating it and maintaining it.
I tried to get familiar with the code, being a big application with mixed functional code and dom manipulation it took me to long for my limited time to improve or add a piece. Also, not having my code running on a local machine as CP is in jsfiddles, I gave up.
The code structure of LaserWeb and LaserWeb2 faces the same problem as CP.
- UI code is mixed with functional code.
- Functional code is not tested. Maintaining, building projects like this and keeping them alive by one person is hard. And in that matter we should join forces together. I'm pretty sure Peter wouldn't mind to have his gcode generators for laser engraving and cutting implemented in CP. But I guess from his perspective he chose the easy way, to build it himself and learn javascript on the job.
If people are not comfortable in a codebase, it's sometimes easier to synthesize there own version of it. I'll see this behaviour often with my own employees when they deal with bigger projects they need to alter, or when they should or could reused other code.
Splitting big codebases into functional modules with descriptive api's like most of the npm modules, can make things easier.
In this case I can image we could build an npm module with a clear api that handles everything, that has to do with the listing, connecting, disconnecting, resume connection, messaging and ... with serial port json websocket server.
Only functional, no UI manipulation. You can subscribe to events for manipulating you UI.
This module can be tested. That way the fear of breaking stuff is minimized. It makes it a lot more reusable, and less cumbersome to try to make your own version of it.
By no means this is meant as criticism. I like the hard work of everyone involved in these open source cnc'ing projects.
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com//issues/19#issuecomment-207006397
@johnlauer well, i'd still prefer to use this as my playarea (: and its not meant to compete with CP in any way shape or form,
So if you don't mind, can we still bug your brain for some questions on SPJS (seeing as thats what I am using as our websocket to serial bridge since the node-serialport approach had a bit too many bugs)
- What is the approach to reconnecting an open port after browser refresh? Close it again then reopen? Or are you simply checking if the port is already open and updating the UI accordingly (and allow new wsSends)
- With SPJS: How do (preferably buffer agnositacally) respectively pause, and stop?
Figured out play/pause - test on Grbl, not sure if the !~% will be handled by SPJS for the Marlin buffer too
If you look at the TinyG buffer, and really the general buffer template interface, there is a method called to see if a command needs to be moved to the front of the queue like !~%. You need to implement that in your buffer to get those commands to jump forward. Keep in mind those commands don't wait to be sent then, which means you need to ALWAYS leave about 5 bytes free in your serial buffer on the device, i.e. don't ever really max the 256 bytes in the main queue. I max the queue at 200 bytes to be safe that I always have 56 bytes for immediate commands. Also, make sure no one gcode line is longer than 200 bytes then (or whatever number you pick for the main queue).
so !~ isnt intercepted by spjs to "stop sending" - its actually just passed along to the board to feedhold, resume. % is intercepted by spjs to "wipe" its buffer?
Yes, SPJS also does it's own cool stuff on those commands that each buffer can implement. there are checks for whether a command should wipe the buffer and if true is returned, it wipes locally too. so if % is sent it checks that the cmd should "not be buffered" and it checks if the command should wipe locally and if true which % would be it wipes the local queue too.
Ok cool. I may be sending more pulls for spjs buffer soon. I will also
need to add that then (:
On 10 Apr 2016 21:33, "John Lauer" notifications@github.com wrote:
Yes, SPJS also does it's own cool stuff on those commands that each buffer
can implement. there are checks for whether a command should wipe the
buffer and if true is returned, it wipes locally too. so if % is sent it
checks that the cmd should "not be buffered" and it checks if the command
should wipe locally and if true which % would be it wipes the local queue
too.—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#19 (comment)