@jlauer I have a question: in the spjs widget how can we send a command “outside” the buffer. I mean when gcode is running we need to send the “safety door” command, but it goes to the queue. I don’t understand why other commands like “!” aren’t queued in the buffer. I see in the pubsub and couldn’t find any way to do that.
Take a look at the docs on the Github page. There’s a command called “sendnobuf”. https://github.com/chilipeppr/serial-port-json-server
An alternate way would be to modify the actual code of the buffer which is what detects specific commands that the buffer knows should bypass. Keep in mind though if you are going to sendnobuf you can overflow the buffer, because you can possibly (based on timing, which can feel random) send in more than 128 chars and presto, you lost your chars and have no idea what happened.
I see… I think that modify the buffer code to by-pass new commands is the way
You can do sendnobuf right from ChiliPeppr. You just have to use the “/ws/send” pubsub instead of “/send” or “/jsonSend”
uhm… using /ws/send calls:
wsSend: function (msg) { this.conn.send(msg); }
send: function(msg) {
if (this.version != null && this.versionFloat >= 1.4) {
this.sendBuffered(msg);
} else {
this.sendNoBuf(msg);
}
there is no way from pubsub to send with “sendNoBuf” without editing the widget 
file buffer_grbl.go @ line 296: here there is the match to bypass the buffer
if match, _ := regexp.MatchString("[!~\?]|(\u0018)", cmd); match {
log.Printf(“Found cmd that should skip buffer. cmd:%v\n”, cmd)
return true
}
we have to add this unicode char \u0084, \u0085, \u0090 -> \u009E, \u00A0, \u00A1 to the MatchString
What do you think?
“/ws/send” pubsub is low-level sending, meaning you are talking raw to SPJS via pubsub, so any command it supports you can send. The way to think about it is to open the console in the spjs widget and type a command. You are essentially just doing that. Try a sendnobuf in the console in the spjs widget and see if it does the trick. Then just do that via “/ws/send”. you should not have to modify the code of of the spjs widget like you were thinking.
Yes, I have tried and it’s ok to use /ws/send, but when a message arrived to the SPJS server, like the new “real time commands”, they are not passed directly to the serial port
Are you saying they just get queued up like a normal send?
yes I think so because there is this function in https://github.com/chilipeppr/serial-port-json-server/blob/master/bufferflow_grbl.go
func (b *BufferflowGrbl) SeeIfSpecificCommandsShouldSkipBuffer(cmd string) bool {
and it dosn’t include the new commands codes
Hmm. Yeah, I just looked at the code to SPJS and realized that sendnobuf goes right to the send method. I’m sort of starting to remember why I did that. I think I had a need to choose sendnobuf from the browser so I started working on adding it, but never completed it. You are running into the same thing I did a couple years ago. Ultimately I solved it inside the buffer flow code. That may be the way you should do it too, or you could look into hub.go line 207
} else if strings.HasPrefix(sl, “send”) {
// will catch send and sendnobuf
//args := strings.Split(s, "send ")
go spWrite(s)Sorry, but it would not be better to change the match in the bufferflow_grbl with the new command codes? Because other commands like “!” “~” … go directly to the serial port. Or not ?
It would seem you would just add more to the regexp in this code:
func (b BufferflowGrbl) SeeIfSpecificCommandsShouldSkipBuffer(cmd string) bool {
// remove comments
//cmd = regexp.MustCompile("\(.?\)").ReplaceAllString(cmd, “”)
//cmd = regexp.MustCompile(";.*").ReplaceAllString(cmd, “”)
if match, _ := regexp.MatchString("[!~\?]|(\u0018)", cmd); match {
log.Printf(“Found cmd that should skip buffer. cmd:%v\n”, cmd)
return true
}
return false
}
Yes i hope It will be enough
On line 43 of the grbl buffer flow you see this:
b.BufferMax = 127 //max buffer size 127 bytes available
Make sure you leave enough room for your command, based on it’s length, to always leave bytes for commands that would skip buffer. So if your command is 5 chars, change that to 122. Keep in mind then that if somebody has a Gcode line longer than 122 lines it will overflow. That is getting really tight. Most newer controllers allow 256 bytes per line or even 1000.
New commands are 1 char only from extended range ascii codes. so it’s only 8 bits = 1 bytes, so 127 its good, isn’t it?
The gbrl buffer, btw, has always had the original bug where your job can randomly pause. This is due to a thread locking issue that used to exist in TinyG buffer but got stamped out over a year ago. You should just take the TinyG buffer flow code and use it as a new starting point for Grbl buffer flow and then add/change all the Grbl specific stuff.
Since you’re in there editing right now, you should really consider this change as well.
ok, i will ses… what file is that? i see many bufferflow tinyg version