lw.comm-server
lw.comm-server copied to clipboard
LaserWeb
Detect if its a laser or a mill?
Run http://smoothieware.org/console-commands#config-get for the laser_module parameter (if true, its a laser) also could probably check for extruders if found, is a 3d Printer. Check for a Spindle config, its a mill... etc
On Grbl we can check for Laser Mode (if found its a laser. If not its a mill)
Then in the frontend (@jorgerobles) we can hide laser ops and "laser test" etc and any other instance of "laser" if its not a laser
This sounds good for limiting what's on the Control tab. I'm uneasy with it limiting things on the Files tab.
If i may ask? Why? We have a cnc mode switch that hides cnc mill ops (;
On Jun 1, 2017 8:48 PM, "Todd Fleming" [email protected] wrote:
This sounds good for limiting what's on the Control tab. I'm uneasy with it limiting things on the Files tab.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/lw.comm-server/issues/31#issuecomment-305584918, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr21fOtX3lhnHI97Sd8V3evL3A_ZkLks5r_wd9gaJpZM4NtYFj .
Sidenote: it could be true on all 3 of course too
On Jun 1, 2017 8:50 PM, "Peter van der Walt (Gmail)" < [email protected]> wrote:
If i may ask? Why? We have a cnc mode switch that hides cnc mill ops (;
On Jun 1, 2017 8:48 PM, "Todd Fleming" [email protected] wrote:
This sounds good for limiting what's on the Control tab. I'm uneasy with it limiting things on the Files tab.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/lw.comm-server/issues/31#issuecomment-305584918, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr21fOtX3lhnHI97Sd8V3evL3A_ZkLks5r_wd9gaJpZM4NtYFj .
I hate that switch. It contributes to people coming from jscut thinking it's not a complete replacement. They try it, see only laser ops, then quickly give up.
Yip me too, sort of why I want the switch replaced with "what is this machine based on what the firmware tells us"?
Also, want to remove the phrase Laser wherever not absolutely needed - since it scares of mills users seeing a Laser test button, laserweb title bar, etc
I see this happening:
- Beginner tries CAM first
- Connects to a board that they haven't finished configuring
- Gets totally confused that CAM suddenly stops working right
Agreed, quick win there. In default mode we can show all machine ops. After connecting, we know what we are talking to, hide irrelevent ops?
I'll leave my root problem - just in case it inspires a different elegant solution to the problem:
I have several machines in my shop: would be cool if LW adapts to the particular machine I connected to, when I connect to it. On the one hand I thought, simple enough, check the firmware to see what tools are configured. The other idea I had was to find a hash / serial number / something from the serial port, and automatically switch Machine Profiles based on the ID of the port you connect to (and no port name is not good enough, /dev/ttyUSB0 isnt always the mill (; ) - this idea of course would be even better since it can then adapt machine sizes, origins, gcode etc all based on which machine i am presently connected to)
Understood. I think machine should connect on user interaction, and once connected, there's a work in progress https://github.com/LaserWeb/lw.comm-server/wiki/Firmware-feature-list that might solve that.
I have the same issue as Peter, but what happens if I want to work in another comouter or not connected? Or shows all ops on not connection, switch to specific when connected
I belief that the user should always initiate the connection because on some machines it's not save to connect without user knowing it (i.e. eleksmaker machine activates laser on connect!).
The planned getFeatureList command could be easily extended by featuresLaser, featuresMilling or a "serial number" if I can detect those infos somehow.
What about having a firmware configuration dialog in LW4?
If we can detect some machine serial number, we could name that machine and show that name in the COM-Port dropdown.
The problem with reading the config (like laser module, spindle module, laser mode...) from the firmware is, that we don't know if the user has configured the firmware correctly.
@cprezzi https://github.com/EmergingTechnologyAdvisors/node-serialport#serial-port-list shows Serial number as a result.
Sidenote, all Smoothieware boards have the same pid and vid. Seeing those immediately allows you to assume that port is a smoothie (;
On Jun 1, 2017 11:22 PM, "Claudio Prezzi" [email protected] wrote:
The problem with reading the config (like laser module, spindle module, laser mode...) from the firmware is, that we don't know if the user has configured the firmware correctly.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/lw.comm-server/issues/31#issuecomment-305624401, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr252WZy3SP3rxpZdyo4iJSD4HglLXks5r_yt5gaJpZM4NtYFj .
What do you think about that:
- If the user would have to define a machine profile for every machine, not one profile per machine type, we could store the last machine settings (read from firmware) in the machine profile.
- On every connection, we could compare the machine settings with all profiles and select the first maching one.
This way, we could store all "flags" in the machine profiles.
And the other way around:
- If the user selects a machine profile, we could try to open the last known port for this machine.
I'm not sure. I think machine hardware should have a command to identify their purpose, defined by user. Not so hard ... :)
El 18 jun. 2017 7:40 p. m., "Claudio Prezzi" [email protected] escribió:
And the other way around:
- If the user selects a machine profile, we could try to open the last known port for this machine.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/lw.comm-server/issues/31#issuecomment-309291624, or mute the thread https://github.com/notifications/unsubscribe-auth/ABoIYMbW6VEf-e7E7ZcX2y3flQ2wVlQwks5sFWEIgaJpZM4NtYFj .
On grbl, the user can store an idetification string with $I=xxxxx, but Smoothieware and TinyG don't have such a feature, as far as I know.
What I mean is, that we should save all machine dependant settings for the frontend in the machine profiles. If there is some machine idetification or "serial number" we would also store it in the corresponding machine profile, so we know which settings to load.
I agree. Some vendor machines will come with the features preloaded on their profiles, some other belongs to the firm capabilities. Machine profiles are meant for that, but we have to ask the machines - who are you?
- hope we can get help for other firms than grbl for that.
El 18 jun. 2017 8:00 p. m., "Claudio Prezzi" [email protected] escribió:
What I mean is, that the frontend anyways has to save the settings for his features, so why not in the machine profiles. If there is a machine idetification number (or "serial number") we could store it in the corresponding machine profile, so we know which settings to load.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/lw.comm-server/issues/31#issuecomment-309292702, or mute the thread https://github.com/notifications/unsubscribe-auth/ABoIYHkJQANnglz7f4SpcgvycksU0QZMks5sFWXSgaJpZM4NtYFj .