Any news on chilipeppr be compatible with grbl 1.1?
grbl1.1 with new things like suport laser, feedrate override in real time, among others
anyone willing to make this happen and move foward, almost all controllers softwares are updated with grbl1.1, would be great to see chilipeppr to move foward also
@Justin_Adie and @Luca_Nervetti are working on updates, but would you be up for helping out as well if you know a bit of HTML and Javascript? The more help, the better.
Grbl1.1 support for the new reporting system, jogging interface and real time commands is ready for wider testing ( @Luca_Nervetti do you agree?).
I’m writing a better interface for setting configs at the moment but that is a UI/UX issue and should not affect functionality.
We have not yet specifically added support for lasers - in fact I hadn’t known that was even needed! @Luca_Nervetti have you looked at this at all?
The current compatible workspace is at http://chilipeppr.com/jpadie. I’m hoping to move things on this weekend and issue pull requests for those aspects that are ready for wider integration.
Yes, I’m actually using the new widget for cutting/milling and it works good, also the new real time commands like feedrate increment/reduction and “door alarm”. There are few things to do, but I think it’s better to have some feedback from users for debugging, so we can improve the UI and correct any errors.
@Justin_Adie I think that laser commands are working already, and there is not need to update the UI.
Good news! Thanks
@Justin_Adie I see your CP workspace has the same 1.88 SPJS links. Do you use the same SPJS? I was wondering maybe you can fix the server for the missing responses from grbl that cause a hang until I press “~” in CP. I’ve tried looking at it myself and try to port the tinyg buffer as @jlauer suggested but I’m afraid it’s written in some outlandish-chinese language which I’ve never programmed before 
I’ve tried going g2core route but had other issues even though it’s written in C/C++ so now I’m stuck in the bCNC nightmare
Hi Mircea. Can you extrapolate please?
what are the issues you are facing?
are the issues related to the server (SJPS) or the interface widget?
@Mircea_Russu did you install the last version of SPJS? Here is the link: https://github.com/chilipeppr/serial-port-json-server/releases
@Justin_Adie @Luca_Nervetti As far as I understand it the SPJS misses the “ok” from grbl from time to time. That makes the machine stop moving and I have to press the “~” button in CP (continue cycle) to get it to continue milling. It’s not always in the same place when milling the same gcode. @jlauer said it’s a long known bug and I should try porting the tinyg buffer to the grbl, the tinyg buffer has a 250ms timeout and asks the board again, but I couldn’t do it as I’m not familiar to Java or node or what that SPJS language is.
i have not seen that behaviour. I thought the bug @jlauer mentioned was about thread safety.
If I have time I will look this evening. Go is a silly language but not difficult.
@Justin_Adie I’m still using latest grbl 0.9j and did not switch to 1.1 and your space yet.
I doubt it makes a difference. this seems an entirely unconnected thing
The Grbl buffer in SPJS has a longstanding bug where it thread deadlocks. The Grbl buffer is modeled off of the TinyG buffer. It was hard to find this bug, but it finally got stamped out in the TinyG buffer. The Grbl buffer is still the old code base. It never misses an OK coming back Grbl, rather it marks that the OK came back and releases the buffer lock, but that release happens nanoseconds before the outgoing Gcode sending part of the buffer locks it. If the release happened after the outgoing thread then it would work correctly. If it happens nanoseconds before the outgoing thread you get a deadlock.
Go is a pretty cool language. It’s very much like C or C++ but with enhanced features. The key reason I used it for SPJS was the cross-compiling capability and it’s ability to make threaded programming really easy. It has good JSON support too.
all good info. i will fix the grbl buffer this evening.
@Mircea_Russu
Apologies, having said that I would fix the grbl buffer yesterday I have missed that target. I rewrote it last night but did not have time to test it. This morning I find that my commit via cloud9 has not stuck and the revised code has been lost.
So I won’t have rewritten the buffer before this evening (European time).
@Justin_Adie Thank you for looking at this. There is no hurry, I’ve tried looking at it myself and and thought about adding time.Sleep(1 * time.Millisecond) in OnIncomingData() before each b.SetPaused(false, 2). A crude way to make sure the race condition @jlauer was talking about never happens, but I’ve read you’re looking at it and decided to wait a few more days
@Mircea_Russu it’s a race condition that should be handled through thread locking if I read @jlauer correctly. I have looked through the code and could not really see where it would occur, nor have I ever seen it occur myself. But I am using slow machines - so this might be why.
So I am taking @jlauer at his word and just implementing the tiny bufferflow for grbl. There are a few things that need special handling in grbl, and of course tiny bufferflow is written for exchange of json messages: so that needs to be unpicked and reversed into the grbl message flow.
it’s only a coupe of hours of work. I’m unsure why no-one has done it before if it is genuinely an issue that people run into. Perhaps the CP + grbl community is very small.
@Justin_Adie I’ve tried ditching grbl in favour of tinyg but I’m not willing to pay $150 for a controller, I’ve tried g2core on an Arduino Due plus a level converting shield since I don’t want to ditch my 3axis TB6560 original board, after solving the level converting via mosfets since TXB0108 failed miserably I had serious issues with auto-level probing and I almost exclusively do PCBs so without auto-level the machine is useless. After wasting two weeks with the g2core I’ve returned to grbl which does what’s needed and I’m more than happy with my milling, except the damn hanging bug. By the way my controller is an Arduino Nano soldered to half of my parallel cable that came with the machine and tied to an OrangePi for wireless operation from my laptop
Innovative solution @Mircea_Russu !
I guess you sourced some very fast n channel MOSFETs for level conversion.
@Justin_Adie I’ve used some FDN337N fets. G2core has high active step signal and the board needs active low so the mosfets also take care of inverting the signal. The problem is the probe input, either via the JP-382a board or directly wired to the due, debounced via capacitor it still fails to record some transitions and cause unrecoverable errors. So after wasting 2 weeks with it I gave up and returned to grbl. I’ve tried bCNC but can’t get used to the spartan interface and weird mode of autoleveling.