I only used my creality with the sharpie pen for that demo on my GRBL controller. Then I put it back together and learned to 3d print.
I also learned freecad to create the 3d stuff that i've printed. It has a tool path generator that may make g-code files for a mill...
I'm thinking of buying a cheap cnc mill like the one you pointed out on amazon also...
You need to make a frosting extruder for decorating cookies...
@mwroberts said:
In NCO duty cycle my base period is 1uSec. If I set it to 2uSec it would work and I would have to double the Y "velocity" adder that would be added 500,000/sec instead of 1,000,000/sec.
I'll have to think about if NCO frequency mode would work here...
NCO frequency and NCO duty mode behave very similar. The text describing them is exactly the same except:
%00110 = NCO frequency
The pin output will reflect Z[31].
%00111 = NCO duty
The pin output will reflect Z overflow.
So the number of pulses for the same X and Y input will be the same but duty mode outputs a narrow pulse of one base period and frequency mode outputs 50% duty cycle. You just have to make sure to prime the phase (X[31:16]) with $4000_0000 so that the pulses are centered to avoid setup/hold time problems with the DIR signal.
@mwroberts I've never used GRBL, but it seems that is what most people are using, at least on the low end things I'm looking at...
I'm curious as to how your implementation current compares to GRBL in terms of the number of g-codes supported...
Imagine you just did enough to make it work for you, is that fair? Or, is it 100% implemented?
It seems to have enough to get my job done even without jog...
BTW: I'm leaning towards adding a 7" HDMI screen with USB touch to the code to provide local feedback and control. That should put it several steps ahead of what GRBL could ever do...
@Rayman
My latest rev of GRBL has most of the GRBL standard G-codes supported. And it's 5 axis.
I've been working on P2 GRBL mostly for the challenge and satisfaction of getting it to actually work... and we could use something like this in the OBEX for all to use and hack into...
So, no, I don't have a personal use for a P2 GRBL but i've been learning a lot by doing it.
My intention is to keep adding functionality and get it into the OBEX for others to use.
Your tiny user interface will make it stand alone...
I get sidetracked by dshot, oneshot, ahrs, gyro/acc chips... madgewick, P2 floating point, mt6701, lidar, barometers, my new fpv drone, learning liftoff... oh, and work and family usually come first...
@mwroberts Getting ready to test new "a" version with jog...
Another question:
Right now I have enough P2 pins to do cover these:
xHiLmtPin = 28'16
xLoLmtPin = 29'17
yHiLmtPin = 30'18
yLoLmtPin = 31'19
zHiLmtPin = 32'20
zLoLmtPin = 33'21
aHiLmtPin = 34'22
aLoLmtPin = 35'23
bHiLmtPin = 36'22
bLoLmtPin = 37'23
Probe1Pin = 38'24
Probe2Pin = 39'25
But, this does prevent me from using the PSRAM on P28..P39.
Would bad things happen if I set the ones I don't need to the same pin number?
Like this:
aHiLmtPin = 51
aLoLmtPin = 51
bHiLmtPin = 51
bLoLmtPin = 51
Probe1Pin = 51
Probe2Pin = 51
Or, is there a better way to disable them?
Also, I'm thinking it would be best for me to move these to I2C I/O Expander.
Do you see a major issue with doing that?
Thanks for your help with this!
@Rayman
The only thing it is using them for is to home. I think it's a G38.2 through G38.4 moves that look for a pin state change. if you are not doing that, you can set them all to one pin like asked.
There is also a method, PullUpLimits() that sets them to 15k pullup and sets output high....
@Rayman
you could use the same one input for xlowlimit, ylowlimit and zlowlimit, wire the switches in parallel, and the home moves do one axis at a time. As long as the axis backs off the switch when it is done homing, this would work.
And I think I have some software limits in there that may or may not be functional...
@Rayman
When I was trying jog in UGS yesterday, a single click sent over a jog move that you could modify the feedrate and size with the up/down tabs... but if you held the button down, it would stream out a bunch of tiny moves... like .015mm...
@mwroberts Jog works, thanks! The distance doesn't seem to match with how far it really moves, but that doesn't really matter, there's a display for the actual location anyway.
Actually, it seems to work in mm mode... Think I had some gigantic feed rate in inches mode...
Doesn't the code limit the feed rate?
@Rayman
The code ignores the g20 and g21. It isn't implemented. if you set xpusles so X moves an inch when the display goes from 0 -> 1.000, it's set up for inches. If you set xpulses up so X moves 10mm when the display moves from 0 -> 10.000 then it's set up for mm.
Ok, I see in the GCode that the first thing it does is issue a G0 code to go fast to initial point.
But, in the P2 code, I see this go by the speed set by:
Global_feed := 200
I've increased this and now it goes faster.
But, as soon as it gets to the starting location UGS errors out saying "Error while starting file stream"
@Rayman
I was missing a G94 in the parser, but that didn't fix it...
added cr and lf to end of lines in test1, that didn't fix it either...
maybe a problem with absolute coordinates?
I'm out of time to work on this anymore today...
@mwroberts said:
I don't think I'm doing anything different to make it a rotary axis.
Set the Ascale variable so that a "G1G91A360.0F3600" command rotates 1 revolution.
We can add code if we need to display rollover on A.
I will see what we can do to get the 4th axis to show up on the UGS display.
got the A axis working, but don't really know what settings to use to make the above work...
For XYZ, seems Ascale decides the speed and currently have this:
Xscale := 400_000'80_000 '1_000_000 -> 1000 steps per mm, use 80_000 for X axis on creality ender 3
Yscale := 400_000'80_000 '80_000 for Y axis on creality ender 3
Zscale := 400_000 '400_000 for Z axis on creality ender 3
Ascale := 400_000 '93_000 for extruder axis on creality ender 3
Now, if do:
G1A0.0F100.0 and then G1A2.0F100.0, get one full rotation.
This might work, but maybe will play with ascale to see if can improve resolution...
Comments
Wow, $10? So much for making my own boards...
Did you find a way to buy your creality without the electronics?
If wanted to get a more modern version of CNC for cheap, probably go for this:
https://www.amazon.com/Genmitsu-3018-PRO-Control-Engraving-300x180x45mm/dp/B07P6K9BL3/ref=sr_1_9
@mwroberts What do you think ?
I only used my creality with the sharpie pen for that demo on my GRBL controller. Then I put it back together and learned to 3d print.
I also learned freecad to create the 3d stuff that i've printed. It has a tool path generator that may make g-code files for a mill...
I'm thinking of buying a cheap cnc mill like the one you pointed out on amazon also...
You need to make a frosting extruder for decorating cookies...
NCO frequency and NCO duty mode behave very similar. The text describing them is exactly the same except:
So the number of pulses for the same X and Y input will be the same but duty mode outputs a narrow pulse of one base period and frequency mode outputs 50% duty cycle. You just have to make sure to prime the phase (X[31:16]) with $4000_0000 so that the pulses are centered to avoid setup/hold time problems with the DIR signal.
Have to figure out proper direction sign bit for x and y. From testing with UGS know that positive z should go up
Is there a tool change gcode command that works here?
Kinda neat that one can send gcode commands with web based serial terminal like this one:
https://www.serialterminal.com/index.html
I can see in the Github source code that they were working a gcode sender app as well...
@Rayman no tool change g-codes...
I added jog functionality today...
Jog is great, thanks! I've been thinking about workarounds...
@mwroberts I've never used GRBL, but it seems that is what most people are using, at least on the low end things I'm looking at...
I'm curious as to how your implementation current compares to GRBL in terms of the number of g-codes supported...
Imagine you just did enough to make it work for you, is that fair? Or, is it 100% implemented?
It seems to have enough to get my job done even without jog...
BTW: I'm leaning towards adding a 7" HDMI screen with USB touch to the code to provide local feedback and control. That should put it several steps ahead of what GRBL could ever do...
@Rayman
My latest rev of GRBL has most of the GRBL standard G-codes supported. And it's 5 axis.
I've been working on P2 GRBL mostly for the challenge and satisfaction of getting it to actually work... and we could use something like this in the OBEX for all to use and hack into...
So, no, I don't have a personal use for a P2 GRBL but i've been learning a lot by doing it.
My intention is to keep adding functionality and get it into the OBEX for others to use.
Your tiny user interface will make it stand alone...
I get sidetracked by dshot, oneshot, ahrs, gyro/acc chips... madgewick, P2 floating point, mt6701, lidar, barometers, my new fpv drone, learning liftoff... oh, and work and family usually come first...
@mwroberts Getting ready to test new "a" version with jog...
Another question:
Right now I have enough P2 pins to do cover these:
xHiLmtPin = 28'16
xLoLmtPin = 29'17
yHiLmtPin = 30'18
yLoLmtPin = 31'19
zHiLmtPin = 32'20
zLoLmtPin = 33'21
aHiLmtPin = 34'22
aLoLmtPin = 35'23
bHiLmtPin = 36'22
bLoLmtPin = 37'23
Probe1Pin = 38'24
Probe2Pin = 39'25
But, this does prevent me from using the PSRAM on P28..P39.
Would bad things happen if I set the ones I don't need to the same pin number?
Like this:
aHiLmtPin = 51
aLoLmtPin = 51
bHiLmtPin = 51
bLoLmtPin = 51
Probe1Pin = 51
Probe2Pin = 51
Or, is there a better way to disable them?
Also, I'm thinking it would be best for me to move these to I2C I/O Expander.
Do you see a major issue with doing that?
Thanks for your help with this!
@Rayman
The only thing it is using them for is to home. I think it's a G38.2 through G38.4 moves that look for a pin state change. if you are not doing that, you can set them all to one pin like asked.
There is also a method, PullUpLimits() that sets them to 15k pullup and sets output high....
@Rayman
you could use the same one input for xlowlimit, ylowlimit and zlowlimit, wire the switches in parallel, and the home moves do one axis at a time. As long as the axis backs off the switch when it is done homing, this would work.
And I think I have some software limits in there that may or may not be functional...
@Rayman
When I was trying jog in UGS yesterday, a single click sent over a jog move that you could modify the feedrate and size with the up/down tabs... but if you held the button down, it would stream out a bunch of tiny moves... like .015mm...
@mwroberts Jog works, thanks! The distance doesn't seem to match with how far it really moves, but that doesn't really matter, there's a display for the actual location anyway.
Actually, it seems to work in mm mode... Think I had some gigantic feed rate in inches mode...
Doesn't the code limit the feed rate?
Think I should just stay in mm mode...
@Rayman
The code ignores the g20 and g21. It isn't implemented. if you set xpusles so X moves an inch when the display goes from 0 -> 1.000, it's set up for inches. If you set xpulses up so X moves 10mm when the display moves from 0 -> 10.000 then it's set up for mm.
I seem to have my X and Y reversed somehow.
I'm thinking it should be like it is here:
https://faculty.etsu.edu/hemphill/entc3710/nc-prog/nc-02-01.htm#:~:text=For lathes, the X-axis,and have no Y-axis.
Ok, trying to draw some text on paper, like you did @mwroberts
But, UGS is moving incredibly slow... I can go 2X faster I think with "overrides", but it's still too slow.
Any way to make it faster?
Ok, I see in the GCode that the first thing it does is issue a G0 code to go fast to initial point.
But, in the P2 code, I see this go by the speed set by:
Global_feed := 200
I've increased this and now it goes faster.
But, as soon as it gets to the starting location UGS errors out saying "Error while starting file stream"
Seeing this:
Or, maybe it's from an earlier command? Not sure why the feed comes first in this G1 command:
Made my own gcode file and it works fine...
It's really bizarre because I can copy the gcode that breaks into my gcode file and it runs just fine...
I made gcode to do a box and then added gcode from UGS to draw letter "T" and it works.
Very strange. It's as if UGS is broke...
@Rayman
Test1.gcode.txt doesn't work for me either...
I included this g-code file in the post...
"parallax3krom2.txt"
I loaded that into UGS and it worked...
So, not sure what's going on yet...
Your gcode seems to work (after reducing all the speeds ~factor of 10x)
Wonder what the difference is... Maybe outline vs. fill mode...
Maybe not a perfect rendition, but not horrible...
@Rayman
I was missing a G94 in the parser, but that didn't fix it...
added cr and lf to end of lines in test1, that didn't fix it either...
maybe a problem with absolute coordinates?
I'm out of time to work on this anymore today...
No problem. Thanks for looking at it. I need to focus on egg painting now anyway...
got the A axis working, but don't really know what settings to use to make the above work...
For XYZ, seems Ascale decides the speed and currently have this:
Now, if do:
G1A0.0F100.0 and then G1A2.0F100.0, get one full rotation.
This might work, but maybe will play with ascale to see if can improve resolution...