Closed cojarbi closed 8 years ago
Here is another gcode. This one seems to skip dots in the same line and then does them on the return. GRBL skips dots.gcode.TXT
Another one. Long Y movement towerds the end of the code. Also a lot of hiccups during line codes ( stops for less than a second ) LADY long vertical movement GCODE-LaserWeb (1).gcode.txt
@nathanielstenzel (; - I am too busy at work this week :(
I wondered where you went, I am used to seeing you spending tons more time working on this project. Don't worry about the schematic for my project, I will buckle down and relearn how to use eagle. While you are busy at work I will try to finish up the Wiki for LaserWeb, I am about 95% complete now.
When did this start happening and when was your last update before that?
I started with GRBL yesterday so I think there have been 2 commits after that. It's started since I connected yesterday.
Ariel Yahni
On Jan 25, 2016, 23:05, at 23:05, Nathan Stenzel notifications@github.com wrote:
When did this start happening and when was your last update before that?
Reply to this email directly or view it on GitHub: https://github.com/openhardwarecoza/LaserWeb/issues/85#issuecomment-174807306
@funinthefalls yeah that festive slowdown is over! Work sits in piles in my desk :(
I have made a mistake in the title, so all this issues are for 0.9g modified by Jtech
Stock grbl. 9j uses power range 0-10000 so 9g should also use the same. That's why jtech compiled it differently
@cojarbi not only that , after reading through shapeoko forum this is what I got , grbl flushes the buffer before changing spindle speed. So when there is a spindle speed change , grbl assumes that you are using a milling machine and it will not accelerate (it stops ) so that spindle can achieve new speed i.e., machine will not accelerate smoothly through spindle speed changes. In modified versions this is avoided. http://www.shapeoko.com/forum/viewtopic.php?f=3&t=6970&start=10
Right, so while I was at work, looks like you two made some progress.
Do we need to add the m3/m5 to raster still? Or is grbl now honoring the power level change as enough (the less serial data we need to send the better)
More importantly - we need to finish #7 - then you can configure your own machine profile from the UI (go see screenshot at bottom of the thread on issue no 7 I posted a few mins ago) without any coding in the backend...
Today i flashed 0.9j master and modified it to S255. Since laserweb is not seding M03 commands the laser does not turn on. Then changed to 0.9g Jtech and it works even though no M03 comands are present on the gcode but there are some random laser on/off and random movements
@cojarbi Edit the gcode(add m3 at the beining and m5 at the end) that's what i'm doing
@openhardwarecoza grbl 0.9j requires m3 and m5
In https://github.com/openhardwarecoza/LaserWeb/blob/master/i/raster/laserraster.js#L223
if (this.config.useVariableSpeed) {
this.result += 'G1 X{0} Y{1} S{2} F{3}\n'.format(posx, gcodey, lastIntensity, speed);
} else {
this.result += 'G1 X{0} Y{1} S{2}\n'.format(posx, gcodey, lastIntensity);
}
Change to
if (this.config.useVariableSpeed) {
if (this.config.firmware.indexOf('Grbl') == 0) {
this.result += 'M3\n';
}
this.result += 'G1 X{0} Y{1} S{2} F{3}\n'.format(posx, gcodey, lastIntensity, speed);
if (this.config.firmware.indexOf('Grbl') == 0) {
this.result += 'M5\n';
}
} else {
if (this.config.firmware.indexOf('Grbl') == 0) {
this.result += 'M3\n';
}
this.result += 'G1 X{0} Y{1} S{2}\n'.format(posx, gcodey, lastIntensity);
if (this.config.firmware.indexOf('Grbl') == 0) {
this.result += 'M5\n';
}
}
Pushed - do a git pull update and let me know!
There're m3 and m5 commands and laser output, but noticed several unwanted movements (even though machine comes back to the required position) and there was a long pause at a time (I didn't do full engraving, so don't know if there's more than one).
I also like to mention one more thing,I generated a raster gcode using laserweb , downloaded the generated gcode, manually inserted M3 and M5 command and run it by laserweb, later I run the same gcode using chilipeppr and result was quite different from what I got from laserweb. In laserweb there was lots of gaps ( there's wasn't laser sometimes) and error messages were invalid gcode ID:24 and bad number format
Top one in the image is from chilipeppr and bottom one from laserweb
I'm also attaching modified gcode(manually inserted m3 and m5) and gcode I got after new fix (raster with M3 and M5) and png image
manually inserted M3 and M5.docx
raster with m3 and m5.docx
Was SPJS shutdown while you were testing with Laserweb? Those unknown gcode messages pop up when something else talks to the controller at the same time (;
ID:24 doesnt appear in your gcode nor in grbls responses, so looks like something else was talking to that port too
As a sidenote, I wouldnt mind someone working on https://github.com/openhardwarecoza/LaserWeb/issues/21 - so if you feel the serial comms could be better, open a seperate thread (if if we have to use SPJS too (; -)
Mind you, looking back at post one, cojarbi also had a ID2x error in his log... very weird, where is it coming from?
Ok, let me guess. you are both on Mac, and instead of seeing the nicely colored lines, your Jobsware chokes on the ANSI code and prints things like ID24 instead of coloring it :/
It should look like this:
And yes yes, I know I shouldnt hate on mac., But come on.... lol ANSI color codes worked on my first 486dx with a CGA graphics adapter back in 1993!
Gents, fix your Macs: See http://stackoverflow.com/questions/29364326/how-to-use-chalk-terminal-string-styling-done-right so we can get better logs out thats actually usable
Continuing my one sided rant:
Your error says it complains about Number Format Check if the S values match what grbl expects? (decimals etc?)
The docx's you uploaded (Why, theres a big SAVE GCODE button?) shows the m3/m5s in the right spots now. So i think (to avoid convulated confusing issue threads) we close this one and handle the serial issues (since the exported file runs fine in another host) seperately. I'll open a new issue with debug instructions Since thats not grbl specific... (Chirag had a similar issue with Marlin)
NB: Log seperate issues, for seperate problems (;
@athulsnair and I have something else common I believe. We bough tried chillippeper and now I think that the json serial server could be the issue. I did went over their git asking how to uninstall it completely but the response was that if it's off then should not interfere with anything
kill the process... then its gone (delete the executable if you are scared it is running)
I killed the MF with a laser :)
Just thinking what you said about something else talking in there
Ariel Yahni
On Jan 29, 2016, 08:39, at 08:39, Peter van der Walt notifications@github.com wrote:
kill the process... then its gone (delete the executable if you are scared it is running)
Reply to this email directly or view it on GitHub: https://github.com/openhardwarecoza/LaserWeb/issues/85#issuecomment-176759887
@openhardwarecoza I'm windows 10 user not MAC
And I don't know anything about coding .I'm trying to modify my X carve in to a laser cutter and testing it by using laser web. Are you saying JSON server that I use for the chilipeppr is communicating with the serial port ?? and that's why I'm getting all the errors??
Its possible, but refer the other issue.. We have a few prople working on this now. Sit tight for a day or two, we'll fix the serial bug soon
First some errors on the terminal. I dont think i saw them yersterday. See attached
Also random vertical movements in the middle of lasering. I could not replicated back to back the same movement but in all test the is a vertical one. Attached gcode
Movement with machine control also turn on the laser. Same procedure to shut down
At the end of the run the laser stays On. Only way to shut it down is first M03 and then M05 grbl error terminal LW.txt grbl jtech GCODE-LaserWeb (1).gcode.txt