Closed ghost closed 8 years ago
ghost
commented
8 years ago (: Oops looks like we'll need to do a seperate staging if you want to use auto merge (: The autogenerated files gets included in the commit after all and you wouldnt want to merge that probably?
Either way, this is actually very little code can can be picked from widget.html and widget.js from https://github.com/chilipeppr/widget-3dviewer/pull/1/files
chilipeppr
commented
8 years ago Hi Peter, I'd love to slurp this change into the main TinyG workspace or really into the 3d viewer, but I don't think the Laser Mode is appropriate for the toolbar you placed it in. The Laser Mode seems to be content specific and machine specific. That toolbar I'm trying to keep centered around just 3d viewer issues/topics. For content I think a content widget makes more sense that the user possibly opens manually or the widget opens automatically if the user loads a file that's a laser specific. So my best thought is a "Laser" widget pops open if the gcode file dragged into CP has S parameters that appear to be for lasering.
Is there a way to detect a laser gcode file from normal gcode?
On Fri, Feb 12, 2016 at 5:52 AM, Peter van der Walt < notifications@github.com> wrote:
(: Oops looks like we'll need to do a seperate staging if you want to use auto merge (: The autogenerated files gets included in the commit after all and you wouldnt want to merge that probably?
Either way, this is actually very little code can can be picked from widget.html and widget.js from https://github.com/chilipeppr/widget-3dviewer/pull/1/files
— Reply to this email directly or view it on GitHub https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183338120 .
ghost
commented
8 years ago That is a tricky one, so your comments are valid and i appreciate input.
From a gcode perspective, laser power = spindle speed so the presense of a S param isnt a given.
Its a user question (am i loading gcode where i want higher S values to show up as darker moves, and lower s values as lighter shade) - mind you spindle users could use that too actually.
But its functions is entirely related to the 3d viewer. It determines what the viewer will accept as S??? = 100% opacity (and whether to even parse S at all [not added in current pull yet]
One way to automate the s value is if we can subscribe somewhere to get a firmware version (i'll post how i do it in LaserWeb in a second) On 12 Feb 2016 19:36, "John Lauer" notifications@github.com wrote:
Hi Peter, I'd love to slurp this change into the main TinyG workspace or really into the 3d viewer, but I don't think the Laser Mode is appropriate for the toolbar you placed it in. The Laser Mode seems to be content specific and machine specific. That toolbar I'm trying to keep centered around just 3d viewer issues/topics. For content I think a content widget makes more sense that the user possibly opens manually or the widget opens automatically if the user loads a file that's a laser specific. So my best thought is a "Laser" widget pops open if the gcode file dragged into CP has S parameters that appear to be for lasering.
Is there a way to detect a laser gcode file from normal gcode?
On Fri, Feb 12, 2016 at 5:52 AM, Peter van der Walt < notifications@github.com> wrote:
(: Oops looks like we'll need to do a seperate staging if you want to use auto merge (: The autogenerated files gets included in the commit after all and you wouldnt want to merge that probably?
Either way, this is actually very little code can can be picked from widget.html and widget.js from https://github.com/chilipeppr/widget-3dviewer/pull/1/files
— Reply to this email directly or view it on GitHub < https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183338120
.
— Reply to this email directly or view it on GitHub https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183423818 .
chilipeppr
commented
8 years ago I see, so the S you're using just for color opacity. Are you saying people need to generate their gcode specific to their machine thus specific to 0-10000 hard coded if one machine or 0-1 hard coded for another? Darn, that's lame. I thought you were converting it for them in their gcode on-the-fly from that menu item.
So, I do think that's more of a 3d viewer specific feature now, but I would need to downplay the label so its not so big. I can figure that out on my own though.
On Fri, Feb 12, 2016 at 9:41 AM, Peter van der Walt < notifications@github.com> wrote:
That is a tricky one, so your comments are valid and i appreciate input.
From a gcode perspective, laser power = spindle speed so the presense of a S param isnt a given.
Its a user question (am i loading gcode where i want higher S values to show up as darker moves, and lower s values as lighter shade) - mind you spindle users could use that too actually.
But its functions is entirely related to the 3d viewer. It determines what the viewer will accept as S??? = 100% opacity (and whether to even parse S at all [not added in current pull yet]
One way to automate the s value is if we can subscribe somewhere to get a firmware version (i'll post how i do it in LaserWeb in a second) On 12 Feb 2016 19:36, "John Lauer" notifications@github.com wrote:
Hi Peter, I'd love to slurp this change into the main TinyG workspace or really into the 3d viewer, but I don't think the Laser Mode is appropriate for the toolbar you placed it in. The Laser Mode seems to be content specific and machine specific. That toolbar I'm trying to keep centered around just 3d viewer issues/topics. For content I think a content widget makes more sense that the user possibly opens manually or the widget opens automatically if the user loads a file that's a laser specific. So my best thought is a "Laser" widget pops open if the gcode file dragged into CP has S parameters that appear to be for lasering.
Is there a way to detect a laser gcode file from normal gcode?
On Fri, Feb 12, 2016 at 5:52 AM, Peter van der Walt < notifications@github.com> wrote:
(: Oops looks like we'll need to do a seperate staging if you want to use auto merge (: The autogenerated files gets included in the commit after all and you wouldnt want to merge that probably?
Either way, this is actually very little code can can be picked from widget.html and widget.js from https://github.com/chilipeppr/widget-3dviewer/pull/1/files
— Reply to this email directly or view it on GitHub <
https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183338120
.
— Reply to this email directly or view it on GitHub < https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183423818
.
— Reply to this email directly or view it on GitHub https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183425691 .
ghost
commented
8 years ago Here is how i automate it:
In my serial app i query the device to have it spit outs its firmware string and parse it into a firmware variable
From here down https://github.com/openhardwarecoza/LaserWeb/blob/master/server.js#L223
Then in the frontend i do if else https://github.com/openhardwarecoza/LaserWeb/blob/master/i/gcode-viewer/gcode-parser.js#L369 On 12 Feb 2016 19:41, "Peter van der Walt (Gmail)" < peter.plaaswerf@gmail.com> wrote:
That is a tricky one, so your comments are valid and i appreciate input.
From a gcode perspective, laser power = spindle speed so the presense of a S param isnt a given.
Its a user question (am i loading gcode where i want higher S values to show up as darker moves, and lower s values as lighter shade) - mind you spindle users could use that too actually.
But its functions is entirely related to the 3d viewer. It determines what the viewer will accept as S??? = 100% opacity (and whether to even parse S at all [not added in current pull yet]
One way to automate the s value is if we can subscribe somewhere to get a firmware version (i'll post how i do it in LaserWeb in a second) On 12 Feb 2016 19:36, "John Lauer" notifications@github.com wrote:
Hi Peter, I'd love to slurp this change into the main TinyG workspace or really into the 3d viewer, but I don't think the Laser Mode is appropriate for the toolbar you placed it in. The Laser Mode seems to be content specific and machine specific. That toolbar I'm trying to keep centered around just 3d viewer issues/topics. For content I think a content widget makes more sense that the user possibly opens manually or the widget opens automatically if the user loads a file that's a laser specific. So my best thought is a "Laser" widget pops open if the gcode file dragged into CP has S parameters that appear to be for lasering.
Is there a way to detect a laser gcode file from normal gcode?
On Fri, Feb 12, 2016 at 5:52 AM, Peter van der Walt < notifications@github.com> wrote:
(: Oops looks like we'll need to do a seperate staging if you want to use auto merge (: The autogenerated files gets included in the commit after all and you wouldnt want to merge that probably?
Either way, this is actually very little code can can be picked from widget.html and widget.js from https://github.com/chilipeppr/widget-3dviewer/pull/1/files
— Reply to this email directly or view it on GitHub < https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183338120
.
— Reply to this email directly or view it on GitHub https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183423818 .
chilipeppr
commented
8 years ago There is a standard pubsub in CP that lets you get the firmware. Look under the TinyG widget pubsub menu item to see.
/com-chilipeppr-interface-cnccontroller/firmware This widget will broadcast out a firmware build/version number when it sees it come in from the CNC controller to help other widgets pivot off of that data. The firmware build number is requested when the /onconnect is seen. Your widget must be loaded to see this signal as there is no request/recv signal implemented (please ask if you need one).
On Fri, Feb 12, 2016 at 9:44 AM, John Lauer jlauer12@gmail.com wrote:
I see, so the S you're using just for color opacity. Are you saying people need to generate their gcode specific to their machine thus specific to 0-10000 hard coded if one machine or 0-1 hard coded for another? Darn, that's lame. I thought you were converting it for them in their gcode on-the-fly from that menu item.
So, I do think that's more of a 3d viewer specific feature now, but I would need to downplay the label so its not so big. I can figure that out on my own though.
On Fri, Feb 12, 2016 at 9:41 AM, Peter van der Walt < notifications@github.com> wrote:
That is a tricky one, so your comments are valid and i appreciate input.
From a gcode perspective, laser power = spindle speed so the presense of a S param isnt a given.
Its a user question (am i loading gcode where i want higher S values to show up as darker moves, and lower s values as lighter shade) - mind you spindle users could use that too actually.
But its functions is entirely related to the 3d viewer. It determines what the viewer will accept as S??? = 100% opacity (and whether to even parse S at all [not added in current pull yet]
One way to automate the s value is if we can subscribe somewhere to get a firmware version (i'll post how i do it in LaserWeb in a second) On 12 Feb 2016 19:36, "John Lauer" notifications@github.com wrote:
Hi Peter, I'd love to slurp this change into the main TinyG workspace or really into the 3d viewer, but I don't think the Laser Mode is appropriate for the toolbar you placed it in. The Laser Mode seems to be content specific and machine specific. That toolbar I'm trying to keep centered around just 3d viewer issues/topics. For content I think a content widget makes more sense that the user possibly opens manually or the widget opens automatically if the user loads a file that's a laser specific. So my best thought is a "Laser" widget pops open if the gcode file dragged into CP has S parameters that appear to be for lasering.
Is there a way to detect a laser gcode file from normal gcode?
On Fri, Feb 12, 2016 at 5:52 AM, Peter van der Walt < notifications@github.com> wrote:
(: Oops looks like we'll need to do a seperate staging if you want to use auto merge (: The autogenerated files gets included in the commit after all and you wouldnt want to merge that probably?
Either way, this is actually very little code can can be picked from widget.html and widget.js from https://github.com/chilipeppr/widget-3dviewer/pull/1/files
— Reply to this email directly or view it on GitHub <
https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183338120
.
— Reply to this email directly or view it on GitHub < https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183423818
.
— Reply to this email directly or view it on GitHub https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183425691 .
ghost
commented
8 years ago Yip. I have been on sonny and arthurs case to standardise this. Its hell, in the cam side i have several same if/else to generate the gcode required by eachhl firmware and its slight differences (they dont even agree on homing commands lol) On 12 Feb 2016 19:44, "John Lauer" notifications@github.com wrote:
I see, so the S you're using just for color opacity. Are you saying people need to generate their gcode specific to their machine thus specific to 0-10000 hard coded if one machine or 0-1 hard coded for another? Darn, that's lame. I thought you were converting it for them in their gcode on-the-fly from that menu item.
So, I do think that's more of a 3d viewer specific feature now, but I would need to downplay the label so its not so big. I can figure that out on my own though.
On Fri, Feb 12, 2016 at 9:41 AM, Peter van der Walt < notifications@github.com> wrote:
That is a tricky one, so your comments are valid and i appreciate input.
From a gcode perspective, laser power = spindle speed so the presense of a S param isnt a given.
Its a user question (am i loading gcode where i want higher S values to show up as darker moves, and lower s values as lighter shade) - mind you spindle users could use that too actually.
But its functions is entirely related to the 3d viewer. It determines what the viewer will accept as S??? = 100% opacity (and whether to even parse S at all [not added in current pull yet]
One way to automate the s value is if we can subscribe somewhere to get a firmware version (i'll post how i do it in LaserWeb in a second) On 12 Feb 2016 19:36, "John Lauer" notifications@github.com wrote:
Hi Peter, I'd love to slurp this change into the main TinyG workspace or really into the 3d viewer, but I don't think the Laser Mode is appropriate for the toolbar you placed it in. The Laser Mode seems to be content specific and machine specific. That toolbar I'm trying to keep centered around just 3d viewer issues/topics. For content I think a content widget makes more sense that the user possibly opens manually or the widget opens automatically if the user loads a file that's a laser specific. So my best thought is a "Laser" widget pops open if the gcode file dragged into CP has S parameters that appear to be for lasering.
Is there a way to detect a laser gcode file from normal gcode?
On Fri, Feb 12, 2016 at 5:52 AM, Peter van der Walt < notifications@github.com> wrote:
(: Oops looks like we'll need to do a seperate staging if you want to use auto merge (: The autogenerated files gets included in the commit after all and you wouldnt want to merge that probably?
Either way, this is actually very little code can can be picked from widget.html and widget.js from https://github.com/chilipeppr/widget-3dviewer/pull/1/files
— Reply to this email directly or view it on GitHub <
https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183338120
.
— Reply to this email directly or view it on GitHub <
https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183423818
.
— Reply to this email directly or view it on GitHub < https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183425691
.
— Reply to this email directly or view it on GitHub https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183426463 .
ghost
commented
8 years ago Ok, so going forward, if we have tinyg, grbl, my upcoming marlin/smoothie/repetier widgets all publish to that /firmware we can use the same if/else in the gcode viewer.
(: laserwebs grbl buffer is totally broken so i was hoping to get them over onto CP (instead of trying to fix the serialport nodejs bug, a month in i am giving up) - and there are a few users relying on the rasters previewing hehe (: On 12 Feb 2016 19:47, "John Lauer" notifications@github.com wrote:
There is a standard pubsub in CP that lets you get the firmware. Look under the TinyG widget pubsub menu item to see.
/com-chilipeppr-interface-cnccontroller/firmware This widget will broadcast out a firmware build/version number when it sees it come in from the CNC controller to help other widgets pivot off of that data. The firmware build number is requested when the /onconnect is seen. Your widget must be loaded to see this signal as there is no request/recv signal implemented (please ask if you need one).
On Fri, Feb 12, 2016 at 9:44 AM, John Lauer jlauer12@gmail.com wrote:
I see, so the S you're using just for color opacity. Are you saying people need to generate their gcode specific to their machine thus specific to 0-10000 hard coded if one machine or 0-1 hard coded for another? Darn, that's lame. I thought you were converting it for them in their gcode on-the-fly from that menu item.
So, I do think that's more of a 3d viewer specific feature now, but I would need to downplay the label so its not so big. I can figure that out on my own though.
On Fri, Feb 12, 2016 at 9:41 AM, Peter van der Walt < notifications@github.com> wrote:
That is a tricky one, so your comments are valid and i appreciate input.
From a gcode perspective, laser power = spindle speed so the presense of a S param isnt a given.
Its a user question (am i loading gcode where i want higher S values to show up as darker moves, and lower s values as lighter shade) - mind you spindle users could use that too actually.
But its functions is entirely related to the 3d viewer. It determines what the viewer will accept as S??? = 100% opacity (and whether to even parse S at all [not added in current pull yet]
One way to automate the s value is if we can subscribe somewhere to get a firmware version (i'll post how i do it in LaserWeb in a second) On 12 Feb 2016 19:36, "John Lauer" notifications@github.com wrote:
Hi Peter, I'd love to slurp this change into the main TinyG workspace or really into the 3d viewer, but I don't think the Laser Mode is appropriate for the toolbar you placed it in. The Laser Mode seems to be content specific and machine specific. That toolbar I'm trying to keep centered around just 3d viewer issues/topics. For content I think a content widget makes more sense that the user possibly opens manually or the widget opens automatically if the user loads a file that's a laser specific. So my best thought is a "Laser" widget pops open if the gcode file dragged into CP has S parameters that appear to be for lasering.
Is there a way to detect a laser gcode file from normal gcode?
On Fri, Feb 12, 2016 at 5:52 AM, Peter van der Walt < notifications@github.com> wrote:
(: Oops looks like we'll need to do a seperate staging if you want to use auto merge (: The autogenerated files gets included in the commit after all and you wouldnt want to merge that probably?
Either way, this is actually very little code can can be picked from widget.html and widget.js from https://github.com/chilipeppr/widget-3dviewer/pull/1/files
— Reply to this email directly or view it on GitHub <
https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183338120
.
— Reply to this email directly or view it on GitHub <
https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183423818
.
— Reply to this email directly or view it on GitHub < https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183425691
.
— Reply to this email directly or view it on GitHub https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183427310 .
chilipeppr
commented
8 years ago Yeah, there's a set of generic pubsubs that each specific machine should implement. We have a really good parallel between TinyG and Grbl right now other that the stuff Grbl just isn't capable of because it runs on such a low-end processor.
From the TinyG menu [image: Inline image 1]
Interface ImplementationDescription com-chilipeppr-interface-cnccontroller The CNC Controller interface is a loosely defined set of publish/subscribe signals. The notion of an interface is taken from object-oriented programming like Java where an interface is defined and then specific implementations of the interface are created. For the sake of a Javascript mashup like what ChiliPeppr is, the interface is just a rule to follow to publish signals and subscribe to signals by different top-level names than the ID of the widget or element implementing the interface. Most widgets/elements will publish and subscribe on their own ID. In this widget we are publishing/subscribing on an interface name. If another controller like Grbl is defined by a member of the community beyond this widget for TinyG, this widget can be forked and used without other widgets needing to be changed and the user could pick a Grbl or TinyG implementation of the interface. Publish
This widget/element publishes the following signals. These signals are owned by this widget/element and are published to all objects inside the ChiliPeppr environment that listen to them via the chilipeppr.subscribe(signal, callback) method. SignalDescription /com-chilipeppr-interface-cnccontroller/feedhold Feedhold (Emergency Stop). This signal is published when user hits the Feedhold button for an emergency stop of the TinyG. Other widgets should see this and stop sending all commands such that even when the plannerresume signal is received when the user clears the queue or cycle starts again, they have to manually start sending code again. So, for example, a Gcode sender widget should place a pause on the sending but allow user to unpause. /com-chilipeppr-interface-cnccontroller/plannerpause This widget will publish this signal when it determines that the planner buffer is too full on the TinyG and all other elements/widgets need to stop sending data. You will be sent a /plannerresume when this widget determines you can start sending again. The TinyG has a buffer of 28 slots for data. You want to fill it up with around 12 commands to give the planner enough data to work on for optimizing velocities of movement. However, you can't overfill the TinyG or it will go nuts with buffer overflows. This signal helps you fire off your data and not worry about it, but simply pause the sending of the data when you see this signal. This signal does rely on the TinyG being in {qv:2} mode which means it will auto-send us a report on the planner every time it changes. This widget watches for those changes to generate the signal. The default setting is when we hit 12 remaining planner buffer slots we will publish this signal. /com-chilipeppr-interface-cnccontroller/plannerresume This widget will send this signal when it is ok to send data to the TinyG again. This widget watches the {qr:[val]} status report from the TinyG to determine when the planner buffer has enough room in it to send more data. You may not always get a 1 to 1 /plannerresume for every /plannerpause sent because we will keep sending /plannerpause signals if we're below threshold, but once back above threshold we'll only send you one /plannerresume. The default setting is to send this signal when we get back to 16 available planner buffer slots. /com-chilipeppr-interface-cnccontroller/axes This widget will normalize the TinyG status report of axis coordinates to send off to other widgets like the XYZ widget. The axes publish payload contains {x:float, y:float, z:float, a:float} If a different CNC controller is implemented, it should normalize the coordinate status reports like this model. The goal of this is to abstract away the specific controller implementation from generic CNC widgets. /com-chilipeppr-interface-cnccontroller/units This widget will normalize the TinyG units to the interface object of units {units: "mm"} or {units: "inch"}. This signal will be published on load or when this widget detects a change in units so other widgets like the XYZ widget can display the units for the coordinates it is displaying. /com-chilipeppr-interface-cnccontroller/coords This widget will broadcast out any change in the coordinate system. The value is {coord:"g55", coordNum: 55} or for G92 {coord:"g92", coordNum: 92} or for machine {coord:"g53", coordNum: 53} /com-chilipeppr-interface-cnccontroller/firmware This widget will broadcast out a firmware build/version number when it sees it come in from the CNC controller to help other widgets pivot off of that data. The firmware build number is requested when the /onconnect is seen. Your widget must be loaded to see this signal as there is no request/recv signal implemented (please ask if you need one).Subscribe
This widget/element subscribes to the following signals. These signals are owned by this widget/element. Other objects inside the ChiliPeppr environment can publish to these signals via the chilipeppr.publish(signal, data) method. SignalDescription /com-chilipeppr-interface-cnccontroller/jogdone We subscribe to a jogdone event so that we can fire off an exclamation point (!) to the TinyG to force it to drop all planner buffer items to stop the jog immediately. /com-chilipeppr-interface-cnccontroller/energizeMotors Send in this signal to fully energize motors so you can do things like a tool change without moving your axis accidentally. This widget will send the correct command to the serial port for your CNC controller. /com-chilipeppr-interface-cnccontroller/unEnergizeMotors Send in this signal to turn off the full power to the motors. Puts motors back into your configured motor settings. This widget will send the correct command to the serial port for your CNC controller. /com-chilipeppr-interface-cnccontroller/requestCoords Send in this signal to request a callback signal of "/com-chilipeppr-interface-cnccontroller/coords" to be sent back. You wil be sent whatever value this widget currently has stored as the last coordinates.
On Fri, Feb 12, 2016 at 9:50 AM, Peter van der Walt < notifications@github.com> wrote:
Ok, so going forward, if we have tinyg, grbl, my upcoming marlin/smoothie/repetier widgets all publish to that /firmware we can use the same if/else in the gcode viewer.
(: laserwebs grbl buffer is totally broken so i was hoping to get them over onto CP (instead of trying to fix the serialport nodejs bug, a month in i am giving up) - and there are a few users relying on the rasters previewing hehe (: On 12 Feb 2016 19:47, "John Lauer" notifications@github.com wrote:
There is a standard pubsub in CP that lets you get the firmware. Look under the TinyG widget pubsub menu item to see.
/com-chilipeppr-interface-cnccontroller/firmware This widget will broadcast out a firmware build/version number when it sees it come in from the CNC controller to help other widgets pivot off of that data. The firmware build number is requested when the /onconnect is seen. Your widget must be loaded to see this signal as there is no request/recv signal implemented (please ask if you need one).
On Fri, Feb 12, 2016 at 9:44 AM, John Lauer jlauer12@gmail.com wrote:
I see, so the S you're using just for color opacity. Are you saying people need to generate their gcode specific to their machine thus specific to 0-10000 hard coded if one machine or 0-1 hard coded for another? Darn, that's lame. I thought you were converting it for them in their gcode on-the-fly from that menu item.
So, I do think that's more of a 3d viewer specific feature now, but I would need to downplay the label so its not so big. I can figure that out on my own though.
On Fri, Feb 12, 2016 at 9:41 AM, Peter van der Walt < notifications@github.com> wrote:
That is a tricky one, so your comments are valid and i appreciate input.
From a gcode perspective, laser power = spindle speed so the presense of a S param isnt a given.
Its a user question (am i loading gcode where i want higher S values to show up as darker moves, and lower s values as lighter shade) - mind you spindle users could use that too actually.
But its functions is entirely related to the 3d viewer. It determines what the viewer will accept as S??? = 100% opacity (and whether to even parse S at all [not added in current pull yet]
One way to automate the s value is if we can subscribe somewhere to get a firmware version (i'll post how i do it in LaserWeb in a second) On 12 Feb 2016 19:36, "John Lauer" notifications@github.com wrote:
Hi Peter, I'd love to slurp this change into the main TinyG workspace or really into the 3d viewer, but I don't think the Laser Mode is appropriate for the toolbar you placed it in. The Laser Mode seems to be content specific and machine specific. That toolbar I'm trying to keep centered around just 3d viewer issues/topics. For content I think a content widget makes more sense that the user possibly opens manually or the widget opens automatically if the user loads a file that's a laser specific. So my best thought is a "Laser" widget pops open if the gcode file dragged into CP has S parameters that appear to be for lasering.
Is there a way to detect a laser gcode file from normal gcode?
On Fri, Feb 12, 2016 at 5:52 AM, Peter van der Walt < notifications@github.com> wrote:
(: Oops looks like we'll need to do a seperate staging if you want to use auto merge (: The autogenerated files gets included in the commit after all and you wouldnt want to merge that probably?
Either way, this is actually very little code can can be picked from widget.html and widget.js from https://github.com/chilipeppr/widget-3dviewer/pull/1/files
— Reply to this email directly or view it on GitHub <
https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183338120
.
— Reply to this email directly or view it on GitHub <
https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183423818
.
— Reply to this email directly or view it on GitHub <
https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183425691
.
— Reply to this email directly or view it on GitHub < https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183427310
.
— Reply to this email directly or view it on GitHub https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183428064 .
ghost
commented
8 years ago Well, we know grbl wants 0-10000 (grbl 0.9j and up, or 0-255 (grbl 0.9i) and what does tinyg accept as spindle pwm range? I guess since marlin/smoothie is still weeks away from me having them done we can ignore them and already do the if/else from that one (: On 12 Feb 2016 19:53, "John Lauer" notifications@github.com wrote:
Yeah, there's a set of generic pubsubs that each specific machine should implement. We have a really good parallel between TinyG and Grbl right now other that the stuff Grbl just isn't capable of because it runs on such a low-end processor.
From the TinyG menu [image: Inline image 1]
Interface ImplementationDescription com-chilipeppr-interface-cnccontroller The CNC Controller interface is a loosely defined set of publish/subscribe signals. The notion of an interface is taken from object-oriented programming like Java where an interface is defined and then specific implementations of the interface are created. For the sake of a Javascript mashup like what ChiliPeppr is, the interface is just a rule to follow to publish signals and subscribe to signals by different top-level names than the ID of the widget or element implementing the interface. Most widgets/elements will publish and subscribe on their own ID. In this widget we are publishing/subscribing on an interface name. If another controller like Grbl is defined by a member of the community beyond this widget for TinyG, this widget can be forked and used without other widgets needing to be changed and the user could pick a Grbl or TinyG implementation of the interface. Publish
This widget/element publishes the following signals. These signals are owned by this widget/element and are published to all objects inside the ChiliPeppr environment that listen to them via the chilipeppr.subscribe(signal, callback) method. SignalDescription /com-chilipeppr-interface-cnccontroller/feedhold Feedhold (Emergency Stop). This signal is published when user hits the Feedhold button for an emergency stop of the TinyG. Other widgets should see this and stop sending all commands such that even when the plannerresume signal is received when the user clears the queue or cycle starts again, they have to manually start sending code again. So, for example, a Gcode sender widget should place a pause on the sending but allow user to unpause. /com-chilipeppr-interface-cnccontroller/plannerpause This widget will publish this signal when it determines that the planner buffer is too full on the TinyG and all other elements/widgets need to stop sending data. You will be sent a /plannerresume when this widget determines you can start sending again. The TinyG has a buffer of 28 slots for data. You want to fill it up with around 12 commands to give the planner enough data to work on for optimizing velocities of movement. However, you can't overfill the TinyG or it will go nuts with buffer overflows. This signal helps you fire off your data and not worry about it, but simply pause the sending of the data when you see this signal. This signal does rely on the TinyG being in {qv:2} mode which means it will auto-send us a report on the planner every time it changes. This widget watches for those changes to generate the signal. The default setting is when we hit 12 remaining planner buffer slots we will publish this signal. /com-chilipeppr-interface-cnccontroller/plannerresume This widget will send this signal when it is ok to send data to the TinyG again. This widget watches the {qr:[val]} status report from the TinyG to determine when the planner buffer has enough room in it to send more data. You may not always get a 1 to 1 /plannerresume for every /plannerpause sent because we will keep sending /plannerpause signals if we're below threshold, but once back above threshold we'll only send you one /plannerresume. The default setting is to send this signal when we get back to 16 available planner buffer slots. /com-chilipeppr-interface-cnccontroller/axes This widget will normalize the TinyG status report of axis coordinates to send off to other widgets like the XYZ widget. The axes publish payload contains {x:float, y:float, z:float, a:float} If a different CNC controller is implemented, it should normalize the coordinate status reports like this model. The goal of this is to abstract away the specific controller implementation from generic CNC widgets. /com-chilipeppr-interface-cnccontroller/units This widget will normalize the TinyG units to the interface object of units {units: "mm"} or {units: "inch"}. This signal will be published on load or when this widget detects a change in units so other widgets like the XYZ widget can display the units for the coordinates it is displaying. /com-chilipeppr-interface-cnccontroller/coords This widget will broadcast out any change in the coordinate system. The value is {coord:"g55", coordNum: 55} or for G92 {coord:"g92", coordNum: 92} or for machine {coord:"g53", coordNum: 53} /com-chilipeppr-interface-cnccontroller/firmware This widget will broadcast out a firmware build/version number when it sees it come in from the CNC controller to help other widgets pivot off of that data. The firmware build number is requested when the /onconnect is seen. Your widget must be loaded to see this signal as there is no request/recv signal implemented (please ask if you need one).Subscribe
This widget/element subscribes to the following signals. These signals are owned by this widget/element. Other objects inside the ChiliPeppr environment can publish to these signals via the chilipeppr.publish(signal, data) method. SignalDescription /com-chilipeppr-interface-cnccontroller/jogdone We subscribe to a jogdone event so that we can fire off an exclamation point (!) to the TinyG to force it to drop all planner buffer items to stop the jog immediately. /com-chilipeppr-interface-cnccontroller/energizeMotors Send in this signal to fully energize motors so you can do things like a tool change without moving your axis accidentally. This widget will send the correct command to the serial port for your CNC controller. /com-chilipeppr-interface-cnccontroller/unEnergizeMotors Send in this signal to turn off the full power to the motors. Puts motors back into your configured motor settings. This widget will send the correct command to the serial port for your CNC controller. /com-chilipeppr-interface-cnccontroller/requestCoords Send in this signal to request a callback signal of "/com-chilipeppr-interface-cnccontroller/coords" to be sent back. You wil be sent whatever value this widget currently has stored as the last coordinates.
On Fri, Feb 12, 2016 at 9:50 AM, Peter van der Walt < notifications@github.com> wrote:
Ok, so going forward, if we have tinyg, grbl, my upcoming marlin/smoothie/repetier widgets all publish to that /firmware we can use the same if/else in the gcode viewer.
(: laserwebs grbl buffer is totally broken so i was hoping to get them over onto CP (instead of trying to fix the serialport nodejs bug, a month in i am giving up) - and there are a few users relying on the rasters previewing hehe (: On 12 Feb 2016 19:47, "John Lauer" notifications@github.com wrote:
There is a standard pubsub in CP that lets you get the firmware. Look under the TinyG widget pubsub menu item to see.
/com-chilipeppr-interface-cnccontroller/firmware This widget will broadcast out a firmware build/version number when it sees it come in from the CNC controller to help other widgets pivot off of that data. The firmware build number is requested when the /onconnect is seen. Your widget must be loaded to see this signal as there is no request/recv signal implemented (please ask if you need one).
On Fri, Feb 12, 2016 at 9:44 AM, John Lauer jlauer12@gmail.com wrote:
I see, so the S you're using just for color opacity. Are you saying people need to generate their gcode specific to their machine thus specific to 0-10000 hard coded if one machine or 0-1 hard coded for another? Darn, that's lame. I thought you were converting it for them in their gcode on-the-fly from that menu item.
So, I do think that's more of a 3d viewer specific feature now, but I would need to downplay the label so its not so big. I can figure that out on my own though.
On Fri, Feb 12, 2016 at 9:41 AM, Peter van der Walt < notifications@github.com> wrote:
That is a tricky one, so your comments are valid and i appreciate input.
From a gcode perspective, laser power = spindle speed so the presense of a S param isnt a given.
Its a user question (am i loading gcode where i want higher S values to show up as darker moves, and lower s values as lighter shade) - mind you spindle users could use that too actually.
But its functions is entirely related to the 3d viewer. It determines what the viewer will accept as S??? = 100% opacity (and whether to even parse S at all [not added in current pull yet]
One way to automate the s value is if we can subscribe somewhere to get a firmware version (i'll post how i do it in LaserWeb in a second) On 12 Feb 2016 19:36, "John Lauer" notifications@github.com wrote:
Hi Peter, I'd love to slurp this change into the main TinyG workspace or really into the 3d viewer, but I don't think the Laser Mode is appropriate for the toolbar you placed it in. The Laser Mode seems to be content specific and machine specific. That toolbar I'm trying to keep centered around just 3d viewer issues/topics. For content I think a content widget makes more sense that the user possibly opens manually or the widget opens automatically if the user loads a file that's a laser specific. So my best thought is a "Laser" widget pops open if the gcode file dragged into CP has S parameters that appear to be for lasering.
Is there a way to detect a laser gcode file from normal gcode?
On Fri, Feb 12, 2016 at 5:52 AM, Peter van der Walt < notifications@github.com> wrote:
(: Oops looks like we'll need to do a seperate staging if you want to use auto merge (: The autogenerated files gets included in the commit after all and you wouldnt want to merge that probably?
Either way, this is actually very little code can can be picked from widget.html and widget.js from https://github.com/chilipeppr/widget-3dviewer/pull/1/files
— Reply to this email directly or view it on GitHub <
https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183338120
.
— Reply to this email directly or view it on GitHub <
https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183423818
.
— Reply to this email directly or view it on GitHub <
https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183425691
.
— Reply to this email directly or view it on GitHub <
https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183427310
.
— Reply to this email directly or view it on GitHub < https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183428064
.
— Reply to this email directly or view it on GitHub https://github.com/chilipeppr/widget-3dviewer/pull/1#issuecomment-183429149 .
ghost
commented
8 years ago I'll close this PR and send you a nicer one tomorrow with firmware detection. (: thanks for the advice!
For laser cutting we depend a lot on the S parameter on G1 moves. And its really nice, especially for raster jobs, to be able to view it in the gcode viewer
For example G1 X100 Y50 F2400 S128 (if this was grbl <0.9g that S128 means 50% laser for that move)
Attached is a test file (raster from LaserWeb's raster output) GCODE-LaserWeb (1).gcode.zip that you can test with, the changes as in this pull request is live on http://chilipeppr.com/plasma
Here's the result
Usage:
Future enhancement In Laserweb I autodetect the firmware in use to save the user from having to do step 1 first.