.hex file version

[swpaxton66]

Hi patyork,

I downloaded your source code and hope to try out your modified firmware settings for laser cutting and avoiding pauses on tinyG due to S command changes.

Of course I could load up the build and compile it myself but I was hoping to use the .hex file you already complied.

However I see there are 2 files in the project, with different sizes. One file is in the ".../default" directory. It is tinyg.hex at 283KB.

The other file is in the ".../debug" directory. It is tinyg.hex at 320KB.

There are no files in the ".../release" directory.

Which file should I upload to my controller? Or should I recompile the project myself and upload that file?

Thanks,

Scott

[swpaxton66]

Looking into this further it looks obvious that the newest file is in the ".../debug" directory. However I uploaded the firmware and there seems to be no change. There were no errors while uploading the firmware and it appeared to complete successfully. I have basically the identical machine setup that you show in the demo video. Do you have any suggestions?

Thanks,

Scott

[patyork]

It's been a while.

The latest .hex is in "firmware/tinyg/Debug/tinyg.hex" so it sounds like you flashed the correct one for sure.

The only thing I can say is that it works fine up to a certain "Number of S Commands per second". There is more detail in this thread: https://github.com/synthetos/TinyG/issues/114

However, to summarize from a post there:

The firmware changes work well at about 2000 changes ("S" commands) per minute; this equates to my laser's abilities of a .2mm by .2mm approximate burn area at its focal point and an acceptable, if slow, machine rate of 400mm/min. The firmware begins to cause noticeable vibration (due to motors turning off for a few milliseconds on each S call) at around 5000 changes/minute, which is 1000mm/min on my machine.

Basically, I call a "pixel" that I want to burn a .2mmx.2mm "square" and at 400mm/min machine rate, that equates to 2000 "pixels" burned per minute, which is a worst case scenario of 2000 "S" commands called per minute. I can push it to 5000 S commands/minute, but after that point I still get jitters.

Try to figure out how many "S" commands you are doing per minute and compare it to those numbers above, and post back. I think* that that may be the problem.

[swpaxton66]

Thanks.

I am running at 400mm/min. Resolution is 0.2mm run on a 45 degree angle. So the vector on 45 degrees is ~ 0.283mm. If I understand properly then that will give me 1413 worst case possible S commands in one minute. (400 mm/min divided by 0.283mm steps) Looks like it is under the threshold you describe. The velocity is definitely changing. I can hear it and also see it changing in my GUI.

[patyork]

Hmmm.

Actually, I may have been running my jerk, on all axes, a lot higher than normal, although these may be the default values, although with the firmware this should not be an issue at all (the machine should think there won't be a jerk at all, just a constant move):

[xjm] x jerk maximum             20 mm/min^3 * 1 million
[yjm] y jerk maximum             20 mm/min^3 * 1 million
[zjm] z jerk maximum             20 mm/min^3 * 1 million

Other than that, I really don't know. You're not the first person for whom this has not appeared to work. In reality, I haven't heard from anyone for whom it has worked (but this just be a Fallacy of Ignorance or "evidence for absence" issue where if it works, no one says anything). It could be that it works only for me, but I don't know.

One other thing to try is the below GCODE. There is only 1 S command total. You should see the machine move through the S command without noticeably decelerating to 0 at X100 (please note, change the values if you need to so as to not overrun the machine!):

G0 X0
G0 X100
S2000
G0 X200

[swpaxton66]

I already ran a code like you suggested. Seemed to work fine. And yes your jerk settings are cranked! Mine or no where near that high. I will try to bump up the jerk and see what happens.

[swpaxton66]

That's weird. I used the same jerk values as you posted and it got worse. hmmm.

[patyork]

Drop em down a bit.

It's got to be either:

• the machine differneces
• a TinyG version/hardware issue..

Edit:

Crank your feed speed down a bit as well. Start lower and try the simple code first, then maybe up your "pixel" size as well. I'd like to figure this out fully to give anyone else with issues some more stuff to check/try.

[swpaxton66]

Ok just had to brush up on my tinyG settings. Turns out my values were set at 300,000,000 mm/min^3. "Note: Jerk values that are less than 1,000,000 are assumed to be multiplied by 1 million. This keeps from having to keep track of all those zeros. For example, to enter 5 billion the value '5000' can be entered."

When I tried the settings earlier, in reality I reduced the jerk, not increased.

So back to square one. For the file that I am running each physical move of the head is identical. The first ~3000 lines have no S commands and the movement is smooth. As soon as it starts hitting the S commands to turn the laser on and off the velocity takes a dive.

I tried 20,000,000 for jerk (for real this time) and it was worse than my previous setting.

I have to be missing something simple.

[swpaxton66]

Does your hex file have a unique identifier that I can see when I query tinyG in the console? Just to double check it actually loaded properly?

[patyork]

No it doesn't unfortunately. I kept everything the same, including the version, because it seemed to cause a wiping of settings (reset to default) which was inconvenient at best.

[patyork]

If you can run that simple gcode, and it doesn't start decelerating before the midpoint (and accelerating after) then the firmware was flashed.

If it jitters at the midpoint, that is something different. That is a machine and/or tinyg hardware issue.

[swpaxton66]

Guess I can't rule out software that is feeding tinyG either. I know if I try to use chilipeppr it bogs down. If I use CNCjs then it is a lot better. Planner buffer seems normal so I don't think the machine is starved for commands.

I will give UGS a try to see if there is any difference.

I can't hear any sound in your videos from the demos you posted. Is the machine travel totally smooth? Or are there any slight hesitations?

[patyork]

I had music playing in the background so I removed audio. Just listened to the original video to double check, but there is nothing audible from the machine at all - this is how I remember it, and also it looks solid at normal speed as well.

I was using chilipeppr. One thing I do is "overrun" all the edges using big G1 codes (like "G1 X-20; G0 X0") which allows the planner to get ahead during the initial transit and allows the head to get up to the target feed speed. However, the big move in the test code should allow the planner to load all 2 moves, the S code, and get up to target speed.

So an answer on that simple code would be a great start.

[patyork]

Oh, hell, I just realized you said you were moving on 2 axes at a time. I wrote this with 1 axes move (at a time) in mind - is that the issue? I treated the laser like a printer - it moves left-to-right or up-and-down only whilst printing/lasering.

It should treat it the same way moving in both X and Y at a time, but that's something I never got around to testing or using...

[swpaxton66]

Good question. I will output the file now with horizontal moves and see how it goes. I will post back the results soon.

[swpaxton66]

Might be a bit better with the horizontal moves only however it still hesitates.

[swpaxton66]

Maybe just sounds better because there is only 1 motor active instead of 3. (1 have 2 motors on the yaxis)

[patyork]

I do as well.

Run the simple code, on one axis, and let me know if you hear or see any difference. It should roll the whole distance without decelerating/accelerating/jittering at the midpoint:

(please note, change the values if you need to so as to not overrun the machine!):

G0 X0
G0 X100
S2000
G0 X200

Basically, run something similar to that (maybe change values) and let me know exactly what happens.

[swpaxton66]

Just tried another test, horizontal at 1mm resolution. Hesitation still exists. I've had enough for one day. I report back if I have any success later.

Thanks for your input.

Wondering if I need to replace the board with something else...

[swpaxton66]

Sorry, I thought I posted it earlier. The simple code runs with no hesitation.

[patyork]

There are boards available for lasers. I made the tinyG work (for me) because I'm a software guy and it was a challenge, and because the cord was USB, not the freaking 1970's printer pinout that hasn't been on laptops for decades.

[swpaxton66]

One other thing though before I go (haha) I noticed when I run the simple code the planner buffer is up around 29 ~ 30. When I run the code I am trying to execute then the planner buffer hangs around 6.

Just wondering if you would be willing to send me a copy of the gcode file you ran, just to rule out that possibility.

[patyork]

If you want to keep going with it:

• start super simple. Maybe 10mm/min on the simple program
  • If it hesitates, that may be your limit
  • Let me know what point it starts hesitating
  • else, increase by 10mm/min

Also, post everything you can. Your TinyG hardware version (on the board), settings for TinyG, stepper motor types, whether you are using external drivers, etc, etc.

[patyork]

Well, pretty sure the chillipeppr buffer shows how much of the buffer is empty - so 6 is good, it means that there is 20+ executions in the queue already (10 of which are moves).

The best thing to run is just the simple code. Maybe add a new set of lines each time it works fine, to add a S command as well. So your next test might be:

(please note, change the values if you need to so as to not overrun the machine!):

G0 X0
G0 X65
S2001
G0 X130
S2000
G0 X200

[swpaxton66]

Ok here is something interesting. I ran A/B tests with the same file using first CNCjs and then UGS. No other parameters were changed.

I wrote a quick test program so that I could vary resolution. The file only contains G1 moves on 1 axis and no S commands.

So the file just steps moves using the configured resolution. Ex:

G1 X0.2 G1 X0.4 G1 X0.6 etc.

For this test I am using the original tinyG hex file. (Just to note I swapped back to the original tinyG hex file and ran your simple code suggestion to confirm the machine hesitates at the S command. It did hesitate)

Ok what I found is that running this test resolution file the machine hesitates using CNCjs at 0.2mm resolution. Base velocity setting is F1000.

Using UGS with exactly the same file (0.2mm resolution) there are no hesitations. Same file, same base velocity setting.

Later I will go back to your hex file and try running it using UGS. I'm interested to see the results.

Somewhere I think I read you wrote your own custom software to control the machine. Is this correct? Maybe this has something to do with your success as well (no hesitations at 400/min at 0.2 resolution)

[patyork]

Well that sounds like a step forward,  at least. I wrote my own Gcode generator, only. It allows me to set my "pixel intensity -to- laser intensity" function, pixel width, etc., to generate the Goode. What it outputs is basically what I've suggested: .2mm pixel width along one axis at a time, so that shouldn't be a factor. I use chilipeppr to send it to the machine, fyi.

Sent from my Verizon, Samsung Galaxy smartphone -------- Original message --------From: swpaxton66 notifications@github.com Date: 1/8/18 5:40 PM (GMT-08:00) To: patyork/TinyG TinyG@noreply.github.com Cc: Pat York pat.york@nevada.unr.edu, Comment comment@noreply.github.com Subject: Re: [patyork/TinyG] .hex file version (#1) Ok here is something interesting. I ran A/B tests with the same file using first CNCjs and then UGS. No other parameters were changed. I wrote a quick test program so that I could vary resolution. The file only contains G1 moves on 1 axis and no S commands. So the file just steps moves using the configured resolution. Ex: G1 X0.2

G1 X0.4

G1 X0.6

etc. For this test I am using the original tinyG hex file. (Just to note I swapped back to the original tinyG hex file and ran your simple code suggestion to confirm the machine hesitates at the S command. It did hesitate) Ok what I found is that running this test resolution file the machine hesitates using CNCjs at 0.2mm resolution. Base velocity setting is F1000. Using UGS with exactly the same file (0.2mm resolution) there are no hesitations. Same file, same base velocity setting. Later I will go back to your hex file and try running it using UGS. I'm interested to see the results. Somewhere I think I read you wrote your own custom software to control the machine. Is this correct? Maybe this has something to do with your success as well (no hesitations at 400/min at 0.2 resolution)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/patyork/TinyG","title":"patyork/TinyG","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/patyork/TinyG"}},"updates":{"snippets":[{"icon":"PERSON","message":"@swpaxton66 in #1: Ok here is something interesting. I ran A/B tests with the same file using first CNCjs and then UGS. No other parameters were changed.\r\n\r\nI wrote a quick test program so that I could vary resolution. The file only contains G1 moves on 1 axis and no S commands. \r\n\r\nSo the file just steps moves using the configured resolution. Ex:\r\n\r\nG1 X0.2\r\nG1 X0.4\r\nG1 X0.6\r\netc.\r\n\r\nFor this test I am using the original tinyG hex file. (Just to note I swapped back to the original tinyG hex file and ran your simple code suggestion to confirm the machine hesitates at the S command. It did hesitate)\r\n\r\nOk what I found is that running this test resolution file the machine hesitates using CNCjs at 0.2mm resolution. Base velocity setting is F1000.\r\n\r\nUsing UGS with exactly the same file (0.2mm resolution) there are no hesitations. Same file, same base velocity setting.\r\n\r\nLater I will go back to your hex file and try running it using UGS. I'm interested to see the results.\r\n\r\nSomewhere I think I read you wrote your own custom software to control the machine. Is this correct? Maybe this has something to do with your success as well (no hesitations at 400/min at 0.2 resolution)"}],"action":{"name":"View Issue","url":"https://github.com/patyork/TinyG/issues/1#issuecomment-356152936"}}}

[swpaxton66]

Ok. I can confirm that no matter what I do, I get a small hesitation with your hex file when it hits M3Sn. The only other thing I can think of is if you sent me the hex file that you uploaded to your machine. Just to rule out a hex file issue.

Other than that I am out of test options.

And also your tinyG settings

[patyork]

You're not doing an "M3/M5" command with each S command, are you?

Sent from my Verizon, Samsung Galaxy smartphone -------- Original message --------From: swpaxton66 notifications@github.com Date: 1/8/18 6:28 PM (GMT-08:00) To: patyork/TinyG TinyG@noreply.github.com Cc: Pat York pat.york@nevada.unr.edu, Comment comment@noreply.github.com Subject: Re: [patyork/TinyG] .hex file version (#1) Ok. I can confirm that no matter what I do, I get a small hesitation with your hex file when it hits M3Sn. The only other thing I can think of is if you sent me the hex file that you uploaded to your machine. Just to rule out a hex file issue. Other than that I am out of test options.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/patyork/TinyG","title":"patyork/TinyG","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/patyork/TinyG"}},"updates":{"snippets":[{"icon":"PERSON","message":"@swpaxton66 in #1: Ok. I can confirm that no matter what I do, I get a small hesitation with your hex file when it hits M3Sn. The only other thing I can think of is if you sent me the hex file that you uploaded to your machine. Just to rule out a hex file issue.\r\n\r\nOther than that I am out of test options."}],"action":{"name":"View Issue","url":"https://github.com/patyork/TinyG/issues/1#issuecomment-356160589"}}}

[swpaxton66]

No. In my test files I only have one command to turn on the laser using M3S0, so it doesn't actually turn the laser on.

[patyork]

Hmm. Well, the hex file I'm using is the one you've got.. so, I've unfortunately not got an answer for you, and I'm also out of tests to run.

Sent from my Verizon, Samsung Galaxy smartphone -------- Original message --------From: swpaxton66 notifications@github.com Date: 1/8/18 7:14 PM (GMT-08:00) To: patyork/TinyG TinyG@noreply.github.com Cc: Pat York pat.york@nevada.unr.edu, Comment comment@noreply.github.com Subject: Re: [patyork/TinyG] .hex file version (#1) No. In my test files I only have one command to turn on the laser using M3S0, so it doesn't actually turn the laser on.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/patyork/TinyG","title":"patyork/TinyG","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/patyork/TinyG"}},"updates":{"snippets":[{"icon":"PERSON","message":"@swpaxton66 in #1: No. In my test files I only have one command to turn on the laser using M3S0, so it doesn't actually turn the laser on. "}],"action":{"name":"View Issue","url":"https://github.com/patyork/TinyG/issues/1#issuecomment-356167596"}}}

[swpaxton66]

I might be on to something based on your previous question about sending M3/M5 with each S command. The laser gcode generators I use generate a M03 for every S command.

I am doing some testing with turning the laser on with one M03 and then just adjusting the power with only a S command. Of course I can use S0 to turn it off also.

Looks promising so far.

How does the gcode look that you use?

[patyork]

Aha. This specifically fixes S command delay. I purposefully left other command like the M3 and M5 ones that are planned as a stop. My gcode is basically exactly what I've been posting. G1 and S codes alternating one after the other. That example code is basically what I would run to burn a line.

Sent from my Verizon, Samsung Galaxy smartphone -------- Original message --------From: swpaxton66 notifications@github.com Date: 1/8/18 7:40 PM (GMT-08:00) To: patyork/TinyG TinyG@noreply.github.com Cc: Pat York pat.york@nevada.unr.edu, Comment comment@noreply.github.com Subject: Re: [patyork/TinyG] .hex file version (#1) I might be on to something based on your previous question about sending M3/M5 with each S command. The laser gcode generators I use generate a M03 for every S command. I am doing some testing with turning the laser on with one M03 and then just adjusting the power with only a S command. Of course I can use S0 to turn it off also. Looks promising so far. How does the gcode look that you use?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/patyork/TinyG","title":"patyork/TinyG","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/patyork/TinyG"}},"updates":{"snippets":[{"icon":"PERSON","message":"@swpaxton66 in #1: I might be on to something based on your previous question about sending M3/M5 with each S command. The laser gcode generators I use generate a M03 for every S command.\r\n\r\nI am doing some testing with turning the laser on with one M03 and then just adjusting the power with only a S command. Of course I can use S0 to turn it off also.\r\n\r\nLooks promising so far.\r\n\r\nHow does the gcode look that you use?"}],"action":{"name":"View Issue","url":"https://github.com/patyork/TinyG/issues/1#issuecomment-356171089"}}}

[swpaxton66]

Success!

I bet this is the problem with all other users that try your hex code also. I bet all the other programs use M03Sn at every S command where your software generator only uses Sn correct?

So what I have done is manually modified my file to only use Sn when I need to change laser power. From just listening to the motor it sounds smooth. My sweet spot at 0.2mm resolution using CNCjs is 250mm/min. I am running one of my actual files now (it's an image). I am going to run it also in UGS later. UGS seems the most efficient for communication. This same file that I am running bogs down too much in chilipeppr.

[patyork]

Awesome! Keep me posted! That's interesting. M commands are planned as a "decelerate to a stop". I could, in theory, just keep track of whether a M3 has been called and The laser is currently on, and then ignore subsequent M3s. Unfortunately, The tinyg processes m3 and then Sx as 2 separate commands. So right there your planner gets cut in half, capacity wise, which will limit feed speed probably. Good to know though; I will make a point of putting this info everywhere I can. I'll make a FAQ somewhere on the repo also.

Sent from my Verizon, Samsung Galaxy smartphone -------- Original message --------From: swpaxton66 notifications@github.com Date: 1/8/18 8:03 PM (GMT-08:00) To: patyork/TinyG TinyG@noreply.github.com Cc: Pat York pat.york@nevada.unr.edu, Comment comment@noreply.github.com Subject: Re: [patyork/TinyG] .hex file version (#1) Success! I bet this is the problem with all other users that try your hex code also. I bet all the other programs use M03Sn at every S command where your software generator only uses Sn correct? So what I have done is manually modified my file to only use Sn when I need to change laser power. From just listening to the motor it sounds smooth. My sweet spot at 0.2mm resolution using CNCjs is 250mm/min. I am running one of my actual files now (it's an image). I am going to run it also in UGS later. UGS seems the most efficient for communication. This same file that I am running bogs down too much in chilipeppr.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/patyork/TinyG","title":"patyork/TinyG","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/patyork/TinyG"}},"updates":{"snippets":[{"icon":"PERSON","message":"@swpaxton66 in #1: Success!\r\n\r\nI bet this is the problem with all other users that try your hex code also. I bet all the other programs use M03Sn at every S command where your software generator only uses Sn correct?\r\n\r\nSo what I have done is manually modified my file to only use Sn when I need to change laser power. From just listening to the motor it sounds smooth. My sweet spot at 0.2mm resolution using CNCjs is 250mm/min. I am running one of my actual files now (it's an image). I am going to run it also in UGS later. UGS seems the most efficient for communication. This same file that I am running bogs down too much in chilipeppr."}],"action":{"name":"View Issue","url":"https://github.com/patyork/TinyG/issues/1#issuecomment-356173874"}}}