I tried out my widget for the first time today.

CAD & CAM Tool Chain ChiliPeppr
1

I tried out my widget for the first time today. It works well when I use the widget to turn on and off the laser. But because of buffering, the signal I am subscribing to is not the signal that I should trust whether the laser is on. The signal means a laser turn on/off Command has just been buffered. Perhaps I need to subscribe to a recv signal from Serial Port.

Perhaps this is something that needs to be implemented at the SPJS level.

Include is a video of the dashboard driving my machine. Putting a pair of goggles in front of the Webcam is a great way to get a live feed if the video. :slight_smile:

I have also found a bug in my go scale code. The bounding box that 3dviewer has only seems to start at (0,0) instead of the real bounding box of the object. Hmm, more work needed to be done.

2

This is really cool to see. If you are triggering code on the /send and then realizing its too soon because of buffering, there’s a few ways to solve this:

  1. Send your Gcode slower like at 1000ms intervals. You’ll get choppy movements, but each send should be getting executed immediately when sent. I don’t recommend this approach, but its an idea.

  2. Watch the XYZ position coming back from CNC controller and trigger your own code based on position. There’s a macro example called “Watch Gcode Response”. The problem is the position reports on Grbl have to be manually requested. I would suggest this only if you have a TinyG that is telling you them in near real-time.

  3. You could also subscribe to /ws/recv from the serial port and count the “Queued” and “Write” responses. The write response comes back when the line is fully written to the CNC controller. That write is not EXACTLY when its executed, but its the closest thing you’ve got.

3

BTW, can you share what laser you’re using? Is it CO2?

4

I am using a 445nm 2W with a FlexMod P3 driver. The total cost comes out around $200 for the laser. I would recommend getting the right glass since this is class 4 (read: instant blindness). You can see the glass is put in front of the camera hence the red tint.

I notice that the video looks rather crappy especially on the webcam view. I am going to try some screen recorder next.

Now that the bounding box is working, I will most likely wanting to ping you for a merge back on 3dviewer widget.

I think I will try the 3rd option. Given that GRBL buffer is not too big, it wouldn’t be too bad. I also have a 4th option: computer vision. Time to put my computer vision knowledge to work on the webcam feed :slight_smile:

5

I have that laser as well, but it’s the 3.5w blue diode. https://sites.google.com/site/dtrlpf/home/diodes/9mm-445nm

If you are toggling that laser on/off via the FlexMod P3 how are you sending the analog voltage? Via Grbl’s spindle on/off? Are you basically just getting a TTL on/off? Or are you sending variable voltage? Did you bypass the X-Drive constant current buck converter and just have the FlexMod direct into the diode?

6

I have not been able to send analog voltage yet. I am only cutting all the way through at the moment but that would be the next step. This thread contains successful implementation of engraving: http://www.photonlexicon.com/forums/showthread.php/20162-CNC-Laser-Engraving-8bit-Shades-of-Grey-445nm

My friend wired up the laser head for me so I am not entirely sure how he got it hooked up :). I will ask him later.

7

I’m working on an update to SPJS that would enable better line execution tracking. The goal is to have two columns of “checkmarks” in the Gcode widget. The 1st column is “buffered” and the 2nd column is “executed”. To achieve this I am going to allow SPJS to have an ID: passed in per gcode line. This will be an out-of-band ID, not a Gcode line number. Then when SPJS sees that line executed it will pass back whatever ID was passed in. ID’s are strings (but in practice may just be integers).

Then we will have tighter control of pivoting off of executed lines. In TinyG you are only sent the r:{} response once the line is starting execution (not when its done executing). However, that gives very close resolution.

There will be a new Flyout menu button added “Attach macro to this line being executed” which will populate the macro box with the code to track that line to help developers understand how to pivot off of execution.

I think this could solve all of our needs. People could still pause programs in the middle, jog, do tool changes, and the pivot off that line being executed would still work.

8

Jarret, have you thought about only requesting positions for say 5 seconds after a new gcode line is sent through SPJS and then stopping? That non-stop flow of positions seems heavy heavy.

9

At the moment, when we send a gcode line to SPJS for buffering, do we have some form of id? If we do, SPJS can report back to the widget this ID when it completes a line. This will achieve what you suggested @Jarret_Luft .

I have a feeling that all this can be achieved easily with another arduino used only for monitoring the pins. Or just upgrade to a tinyG.

10

Well, when I just use the http://chilipeppr.com/serialport workspace to play with Grbl and connect with your awesome buffer, I get inundated. I can just connect with the default buffer and it’s ok, but in doing some testing it was overwhelming me. The thought was you could just add another timer that would pause those after inactivity and then restart them the moment you see a line come in. Let’s see how it goes. No biggie. I will say, I love how TinyG does it. TinyG takes care of telling you position updates as it thinks they’re relevant.

11

I do also want to say that the serial port widget when used alone with grbl SPJS is unusable

12

I do agree that the console.log() is a bit insane right now. Been trying to figure out a strategy on that one. I just keep the console closed when running production and it runs great.

I think what Dat and I are referring to is the Serial Port workspace.

13

Good strategy on console.

What about deduping position reports at the spjs layer?

14

I never thought about overriding console.log(). Nothing like having multiple brains on a project!

15

For SPJS, here’s a thought on the out-of-band ID’s.

SPJS supports
send [serialPort] data
sendnobuf [serialPort] data

So, how about a:
sendjson { “P”: [serialPort], Data: [ { D: data, ID: “1” }, { D: data, ID: “2” } ] }

This way you can still send in multi-line, which I found critical for speed and ordering of commands because SPJS now sends an acknowledgement and ChiliPeppr waits for the acknowledgement on each send to ensure ordering is correct. This adds delay. However, the multi-line is speedy because it’s one trip and one acknowledgement.

If you don’t want to provide IDs you could then also just send:
sendjson { “P”: [serialPort], Data: [ { D: data }, { D: data } ] }

If you want to send some of those commands as “nobuf” you could add a “buf” : false, so:
sendjson { “P”: [serialPort], Data: [ { D: data, ID: “1”, buf: false }, { D: data, ID: “2” } ] }

16

If you notice I already do this in SPJS. I made changes to 1.6 to gear up for this larger change. You see a queue and a write json response today. The write is sent after the line is buffered. If the serial port writer() thread is paused, the write only comes back after the that pause goes away.

Here’s the wiki write up.

Proposed changes for upcoming release.
Have SPJS support a “sendjson” command so multiple lines or serial port data can be sent in at once, but each line can have an ID attached to it so SPJS can send that ID back once the serial port device has executed the command, as well as still allowing buffered and non-buffered send commands.

If you send in a command like this today to SPJS:
send COM22 G91 G0 Z1 F200\nG90\n

You get back: {“Cmd”:“Queued”,“QCnt”:2,“Type”:[“Buf”,“Buf”],“D”:[“G91 G0 Z1 F200\n”,“G90\n”],“Port”:“COM22”}

Then when each line is executed you get back: {“Cmd”:“Write”,“QCnt”:1,“D”:“G91 G0 Z1 F200\n”,“Port”:“COM22”} {“Cmd”:“Write”,“QCnt”:0,“D”:“G90\n”,“Port”:“COM22”}

As seen above, SPJS is already keeping track of each line and sending a final response when the line is executed. However, it is hard to line up which line is which in a UI. To solve this an ID will be allowed to be passed in per command. This would mean that commands can’t just be sent in as one long string with a newline delimiter. Instead each line should be sent in as a structured object.

It is proposed to send in the line above as:
sendjson { “P”: “COM22”, “Data”: [ { “D”: “G91 G0 Z1 F200\n”, “Id”: “222” }, { “D:” “G90\n”, “Id”: “223” } ] }

Then when SPJS buffers those lines, it will send back:
{“Cmd”:“Queued”,“QCnt”:2,“Data”: [ { “D”: “G91 G0 Z1 F200\n”, “Id”: “222”, “Buf”: true }, { “D”: “G90\n”, “Id”: “223”, “Buf”: true } ],“P”:“COM22”}

Then when SPJS sees those lines executed from the serial device, it will send back:{“Cmd”: “Write”, “QCnt”:1, “D”: “G91 G0 Z1 F200\n”, “Id”: “222”, “P” :“COM22”} {“Cmd”: “Write”, “QCnt”:0, “D”: “G90\n”, “Id”: “223”, “P”: “COM22”}

17
18

@jlauer I checked. I have no Xdrive within the copper housing. Only a FlexMod.