LW4 Integration #2
Comments
|
@cprezzi I just committed some example code to Note that to add new fields to settings, you need to add them to the bottom of |
|
@jorgerobles may also help answer questions. |
|
Thanks @tbfleming. That's a start. Is it correct to place the code that handles the user interactions (like jog, play, pause...) in jog.js? Is it ok to include a comm-server client library into the lib folder and use that lib from com.js and jog.js? How do I access the gcode that has to be run? Via state.gcode? |
yes
yes
yes. lib/ is for anything that doesn't fit into the other folders. Other options include git submodules and npm packages.
I just pushed an example. |
|
Ok. Let's see how far I get ;) |
|
One piece a time, The Ripper said @cprezzi think of So, to bind a library (as lw-comms) to a component is pretty straightforward. If any setting should be remembered by the application, you have to bind it to the Application State thru Anyway, ask any questions you have (on G+if needed), I'm here to help. |
|
@cprezzi have you opened a branch on lw4 for the integration? Do you need help (react or other?) |
|
I dont know if its any help, but I'll post it nonetheless From the days before @tbfleming joined the project, there was a 'dev' branch by @lautr3k which actually had a really nice comms module - maybe some work from there can make your tasks easier (probably not since its not react - well maybe some of the UI inspiration if nothing else) serial: http: Locked up in |
|
(; i quite liked the icons in the console. He also had some websocket status info in the console, and automatic reconnect (see sept 8th) |
|
I did not open a new branch in LW4 yet. I am working locally on a cloned dev-es6 and planned to push directly to dev-es6, as this is a development version and nobody else is working on the same components (com and jog). Is that ok, or should I move my work to a new branch? @openhardwarecoza: Thanks for the hint. I didn't know sebastien already worked on the frontend for comms. I will check it to see if it helps me. At least his styling is nice. The basic communication (USB connect, send command to server, jog) is already working. I am working on the details and stability now. During development I realised that it is not very convenient to have comms in a separate tab of the sidebar. It was better in LW3, when it was always visible in the toolbar. Is it conceivable to have the toolbar also in LW4? |
|
Top toolbar can be a component yes, loaded from components/laserweb.js if
I recall correctly
…On Jan 21, 2017 9:34 PM, "Claudio Prezzi" ***@***.***> wrote:
I did not open a new branch in LW4 yet. I am working locally on a cloned
dev-es6 and planned to push directly to dev-es6, as this is a development
version and nobody else is working on the same components (com and jog). Is
that ok, or should I move my work to a new branch?
@openhardwarecoza <https://github.com/openhardwarecoza>: Thanks for the
hint. I didn't know sebastien allready worked on the frontend for comms. I
will check it to see if it helps me. At least his styling is nice.
The basic communication (USB connect, send command to server, jog) is
allready working. I am working on the details and stability now.
During development I realised that it is not very convenient to have comms
in a separate tab of the sidebar. It was better in LW3, when it was always
visible. Is it conceivable to have the "toolbar" also in LW4?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHVr29KIH4jJpKc8Z0hyL8nHW3MnYS64ks5rUl3WgaJpZM4LfLwO>
.
|
|
The CAM tab is already crammed for space; a toolbar will make this worse. Combining comms and jog sounds good to me. |
|
We could also move the config of the machine interface to the settings tab and only have the connect button and state in jog module. It's unlikely that users will change the machine connection very often. |
|
@cprezzi Indeed, a tiny icon aside the connect with gears, by example could trigger the change to settings pane. About the branching or not from dev-es6 was just to know your preference. Either if a branch is opened, or if you push to dev-es6, We could check / help with the integration if you need it. You are not alone... |
|
@cprezzi, @tbfleming I'm curious, what's is the way to bootstrap the server(ws)/client(app) with webpack? @cprezzi, I'm looking to the comm-server and maybe will be good to create an index with the verbs (i.e. describing the ws api) so we can collaborate implementing frontend/backend. What do you think? (grep |
|
@jorgerobles @tbfleming |
|
@jorgerobles we'll probably keep the webpack dev server separate from the WS server since only devs need the dev server. They'll have to run on different ports if we do it this way. |
|
@jorgerobles I have made a wiki page on gh to document the server api (work in progress). Is that ok, or do you prefer another way. I don't know much about webpack, so I leave that to the experienced people ;) |
|
@DarklyLabs For me the proirity is to bring the lw.comm-server to LW4 first, and then care about performance. |
|
this one? https://github.com/LaserWeb/lw.comm-server/wiki/Client-communication |
|
Ok. I will extend it, once the api has sellted a bit ;) |
|
I could use some help. I need to fill the availabe serial ports to a dropdown by code. The actual form field looks like this: |
|
Hi @cprezzi take a look to https://github.com/LaserWeb/LaserWeb4/blob/dev-es6/src/components/webcam.js#L246 This is the most basic example of how a select is populated with programatic data. |
|
@jorgerobles The websocket communication is not the problem. That's already working ;) |
|
I'm just fighting with some react/redux specific details. |
|
Yes, I had to use it because a weird glitch with other components in the pane. But anyways, the relevant code you should modify is the data attribute
If you are dispatching the action to setSettingsAttrs make sure |
|
How can I integrate the lw.comm-server (the server part) into the LaserWeb4 distro and also start the server in together with npm start? |
|
Seems npm-run-all does this http://stackoverflow.com/questions/30950032/how-can-i-run-multiple-npm-scripts-in-parallel |
|
And to integrate lw.comm-server into LaserWeb4 distro? Is it enough to add lw.comm-server to devDependencies in package.json? |
|
How does npm know where to get it from? |
|
Yep, we know it's not supported, nobody bothered to add it, because as far
as I know before laserweb all host software we've had to interface with
required the user tell the software what firmware it is talking to ( ie no
autodetect ).
If laserweb wants to do autodetect, that'd be a good reason to add this
gcode to smoothie ( and grbl/tinyg if they want to doo ), though as always
I don't know who will do it, I certainly don't have the time.
…On Mon, Feb 27, 2017 at 7:19 PM, jorgerobles ***@***.***> wrote:
[image: image]
<https://cloud.githubusercontent.com/assets/1706080/23373742/9afee560-fd21-11e6-8d0a-6400cc9144db.png>
^^ *Hint, hint*
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGpFQQxZO-NLt_b1sbuY9KW6fdyTNYUks5rgxPAgaJpZM4LfLwO>
.
--
Courage et bonne humeur.
|
|
Personally, I never liked the M115 and its verbose formatting. The output string is already several dozen characters to tell you just a handful of things. That said, it doesn't mean that its not useful. At this point, Grbl's protocol is done. There is no more room in the 328p to make anymore changes. Nor am I particularly interested in trying to cram more in. All development work is now focused on the ARM project. I can take on new protocol tweaks there, but only if they make sense to. |
|
what is currently grbl's response to M115 ?
…On Mon, Feb 27, 2017 at 7:28 PM, Sonny Jeon ***@***.***> wrote:
Personally, I never liked the M115 and its verbose formatting. The output
string is already several dozen characters to tell you just a handful of
things. That said, it doesn't mean that its not useful.
At this point, Grbl's protocol is done. There is no more room in the 328p
to make anymore changes. Nor am I particularly interested in trying to cram
more in. All development work is now focused on the ARM project. I can take
on new protocol tweaks there, but only if they make sense to.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGpFSHUblowwNUHDJ0DdAnagVayYBE5ks5rgxXqgaJpZM4LfLwO>
.
--
Courage et bonne humeur.
|
|
The response is an |
|
Well, we do have Machine Profiles in LW4. Could maybe use that to make the
server check what the user said first?
…On Feb 27, 2017 8:31 PM, "Arthur Wolf" ***@***.***> wrote:
what is currently grbl's response to M115 ?
On Mon, Feb 27, 2017 at 7:28 PM, Sonny Jeon ***@***.***>
wrote:
> Personally, I never liked the M115 and its verbose formatting. The output
> string is already several dozen characters to tell you just a handful of
> things. That said, it doesn't mean that its not useful.
>
> At this point, Grbl's protocol is done. There is no more room in the 328p
> to make anymore changes. Nor am I particularly interested in trying to
cram
> more in. All development work is now focused on the ARM project. I can
take
> on new protocol tweaks there, but only if they make sense to.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#2#
issuecomment-282806665>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/
AAGpFSHUblowwNUHDJ0DdAnagVayYBE5ks5rgxXqgaJpZM4LfLwO>
> .
>
--
Courage et bonne humeur.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHVr229el0FDkFBYVhRLbb-d2xn2fKR1ks5rgxZ8gaJpZM4LfLwO>
.
|
|
I think just having it not throw an error would be useful to autodetecters,
and wouldn't require much code change.
Having it output the build info string would be perfect I expect.
…On Mon, Feb 27, 2017 at 7:33 PM, Sonny Jeon ***@***.***> wrote:
The response is an error: since it's not recognized by the parser. I
suppose I could have it output the build info string and maybe even the
welcome string. That's about all I can do. I can't fit anymore strings into
flash without compromising something.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGpFayl5DeYbrOAxY4fqj7x1qqYnH91ks5rgxb8gaJpZM4LfLwO>
.
--
Courage et bonne humeur.
|
|
Well, it seems that an implementation of M115 will take about 140 bytes of flash. I literally have a few hundred bytes to work with in certain critical configurations. These are generally reserved for bug fixes. I was hoping that it would be a few dozen bytes but it's a no go. So, I'm going to have to pass on this. On the plus side, I'll add M115 in the ARM project (and likely Mega version) to output the build info strings. |
|
@cprezzi While the most efficient method is being resolved, is there any temporary code you can apply to help all the smoothie users get past this problem? |
|
@DarklyLabs I suspect that smoothie users just have to live with it. Remember, it's just when connected via ESP, not USB, and it's only on connect. I think it's not the right solution to complicate the usage for all users, to achieve just a bit more convenience for rare situations. As you see above, nobody is willing to change anything, so why shoud we make a handstand to hide firmware problems? If the maker scene wants to make progress, they have to work out common standards, else everything is slowed down. |
|
On Mon, Feb 27, 2017 at 11:59 PM, Claudio Prezzi ***@***.***> wrote:
@DarklyLabs <https://github.com/DarklyLabs> I suspect that smoothie users
just have to live with it. Remember, it's just when connected via ESP, not
USB, and it's only on connect. I think it's not the right solution to
complicate the usage for all users, to achieve just a bit more convenience
for rare situations.
You can have an option that allows smoothie users to specify they are using
smoothie, and keep autodetection by default ... There's no reason to go
"all or nothing" here, and this is actually a pretty common way to handle
firmware-specific stuff in host software ...
As you see above, nobody is willing to change anything,
That's actually not what happened above ... GRBL doesn't have the space,
Smoothie doesn't have the manpower ( right now ), don't confuse unwilling
and unable.
so why shoud we make a handstand to hide firmware problems?
Because it'd be nice to your users ? All of this is for them after all ...
If the maker scene wants to make progress, they have to work out common
standards, else everything is slowed down.
There are actually a lot of people doing a lot of work to get closer to
standardization, but it has to be done right, and it's a lot of work.
Complaining because it didn't happen today in front of you fast enough is
just going to discourage those who have already put years of effort into it
...
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGpFQD74o1tDmgBvGl4gCj6frqjjG-Zks5rg1VIgaJpZM4LfLwO>
.
--
Courage et bonne humeur.
|
|
@cprezzi I couldnt disagree more. This is not a rare situation. There are still problems with USB where we have to restart our machine everytime 'abort' is pressed. These problems were not present in LW3 with its approach to these conditions. LW is a program using various technologies, Smoothie, GRBL, etc. We cannot stand here and demand a developer to change their firmware because we are not happy with it. Both Arthur and Sonny have been more than accomodating in this discussion to even consider alternatives. There are easy ways as discussed to properly support Smoothie that have been made here. Smoothie IS a KEY platform for LW along with GRBL. I find the comment 'users have to deal with it' a very frustrating one and contrary to the underlying philosophy of Laserweb. Why can't users select their firmware and then the correct behaviour is used? |
|
@chamnit It would be enough to get the string "grbl". After that, we can use $I for the details. @arthurwolf Would't it make more sense to implement $I in smoothieware instead? You don't have space problems, right? |
|
On Tue, Feb 28, 2017 at 12:12 AM, Claudio Prezzi ***@***.***> wrote:
@chamnit <https://github.com/chamnit> It would be enough to get the
string "grbl". After that, we can use $I for the details.
@arthurwolf <https://github.com/arthurwolf> Would't it make more sense to
implement $I in smoothieware instead?
If we are going to have a way to get firmware info we'd probably implement
both M115 and $I, but we'd be very unhappy about it.
You don't have space problems, right?
We actually do, just not as drastic as what grbl is facing, but still
enough that we need to think hard about this sort of small addition.
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGpFU4o3xGcmoH_1REKVefd1neeuSpMks5rg1hhgaJpZM4LfLwO>
.
--
Courage et bonne humeur.
|
|
@cprezzi Please remember that LW is independent of Smoothie or GRBL. |
|
@DarklyLabs The problem with the blocked board after abort should have been solved and has nothing to do with this connect issue. I am only talking about the issue that a $X is needed after connecting via ESP! And we will probably add a button to do that. That's realy no big deal. @arthurwolf I didn't see the newer messages when I wrote about the willingness (while I was writing). But good to see you and Sonny are trying to help! |
|
@arthurwolf I am just frustrated because I am fighting with all the firmware differences/problems since weeks and every time I was asking for something, that you eventually confimed, Jim came afterwards and refused. |
|
@cprezzi There are lots of branches to LW now, dev_comms, es-6, installer versions and it is tricky to keep up to date with them all. For instance, the es-6 version doesn't have your comms in it but does have all the other latest work from Jorge etc. How can we improve on this and have everything in one place? |
|
@DarklyLabs Until now I was only working in dev_comms and I did regularly merge new stuff from dev-es6 to dev_comms. As quick as we have a "stable" enough version on dev_comms, I want to merge my work to dev-es6. Hopefully this will be in the next few days. |
|
I had an idea for the clearing of an alarm, because manually sending $X is not convenient: What if I make the abort button dual state like the pause button? When in alarm state, a click would send $X to clear the alarm, in all other states it would send ctrl-x (and clear the queue). This way, the user could just click the same button twice to first stop the job and then clear the alarm. |
|
On Tue, Feb 28, 2017 at 1:00 AM, Claudio Prezzi ***@***.***> wrote:
@arthurwolf <https://github.com/arthurwolf> I am just frustrated because
I am fighting with all the firmware differences/problems since weeks
We have been fighting firmware differences for *years*. That's no reason to
get upset or frustrated or whatever. It's something we all have to deal
with.
and every time I was asking for something, that you eventually confimed,
Jim came afterwards and refused.
Just because I say I like something doesn't mean it's going to be accepted
in the overall Smoothie project, Jim has a much better knowledge of the
codebase and of the implication of code changes than I do.
The Smoothie project is very active, and a lot of changes are made all the
time, but we are also very strict on what we accept, and have to think very
hard about the consequences of every change.
I'm not trying to disperage Laserweb here, but it's *much* easier to make
change to a javascript interface than it is to make changes to a C++ real
time embedded system ... You have to understand that, because if you
compare how easy it is for you to make change, to how much we scrutinize
changes, yes, you are going to see a big difference.
That shouldn't lead to frustration, it's just the reality of what we do.
If it would have a chancde to be accepted, I would make a PR to treat $I
the same like version, but that seems to be a dead duck.
You shouldn't start with a PR, you should ask on the Smoothie-dev mailing
list what the smoothie community thinks about the feature and your proposed
implementation, this is the proper way of doing it, and it will avoid you
creating code that can then get rejected.
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGpFWIDwiVkQWpiTuA2kDZnB16wixstks5rg2OGgaJpZM4LfLwO>
.
--
Courage et bonne humeur.
|
|
@cprezzi I understand your frustration. Be clear in your mind that if other people/projects are not eager to modify their projects (They will have their own reasons, of course), then go to the KISS way (like @openhardwarecoza machine profiles suggestion) and open an issue on the other people project suggesting the change. It bites self-steem I know. Any end user complain about that issue could be forwarded to "Yes, we are aware of, I've done all on my reach, please check LinkToTheOtherPeopleIssueOpenedByYou". |
|
@arthurwolf I'm not upset, just a bit frustrated because all I try is to improve it for our and your users and sometimes I feel that my inputs are seen as disturbance instead of ideas for improvements, especially from Jim. You seem to be more open for discussion at least. And just for your info, I do know what low level software development means. I did that job for several years. I never did a PR, because I also think it's better to discuss an idea first, but probably I have choosed the wrong media (git issue). Never realized there is a dev mailing list. The thing is: I could easily take a fork and change what ever I want (as suggested by some of your community), but that would not help smoothieware. That's why I prefer to work together. |
|
On Tue, Feb 28, 2017 at 1:24 PM, Claudio Prezzi ***@***.***> wrote:
@arthurwolf <https://github.com/arthurwolf> I'm not upset, just a bit
frustrated because all I try is to improve it for our and your users and
sometimes I feel that my inputs are seen as disturbance instead of ideas
for improvements, especially from Jim. You seem to be more open for
discussion at least.
I'm more of a community manager, and jim is more of a lead developer, so it
would be expected that he has more things to say about new code. He
definitely doesn't think ideas are disturbances, he just has a lot of
things to consider when judging what to add and how to add it.
And just for your info, I do know what low level software development
means. I did that job for several years.
I never did a PR, because I also think it's better to discuss an idea
first, but probably I have choosed the wrong media (git issue). Never
realized there is a dev mailing list.
Yep it's the best place to discuss these sorts of additions/modifications.
The thing is: I could easily take a fork and change what ever I want (as
suggested by some of your community), but that would not help smoothieware.
That's why I prefer to work together.
It'd also be work to keep your fork up to date. We definitely try not to
let forks become too numerous, but we also have to be careful not to let
Smoothie become Marlin. It's a lot of work just to balance the two.
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGpFe9TSxKoxPMFVFLccB-ZjrsmUS3iks5rhBHvgaJpZM4LfLwO>
.
--
Courage et bonne humeur.
|
|
@jorgerobles Thanks for your understanding. I just try to avoid any more sources for misconfiguration issus if anyhow possible. If all users have to select thier firmware just to resolv an issue we have when connecting through ESP8266, that's not efficient and can cause more configuration issues. |
ghost
closed this as 
I'm comming to the point where I need to integrate lw.comm-server into LW4 and need some help how to start. I still have no clue how the react/Redux stuff works. Especially where I have to place my Code and how to access the gcode or save/lose Settings.
@openhardwarecoza, @tbfleming : can one of you give me a Quickstart?
The text was updated successfully, but these errors were encountered: