Forum Replies Created
-
AuthorPosts
-
cmcgrath5035
ModeratorIt can be confusing.
tinyG started as a ‘product’, FW running on an Atmel ATxmega192 in pretty much hard wired fashion. A few folks have coaxed it to compile for other Atmel devices of that class.As more hardware options appeared, it became obvious that tinyG was really a FW feature set running on hardware.
G2 was the original ‘next generation’ tinyG, a superset of the tinyG functionality that took advantage of more powerful, and flexible hardware platforms such as the Due, based on 32 bit Atmel uCs such as the Atmel SAM3X8E.
G2 now morphs to G2Core, a recognition that there are several hardware implementions, including a DUE, that are viable build (compile) targets.
Maybe this will help:
ModeratorOK, you are Due/G2 focussed already.
You are likely to get more help on this at
The devs hang out there and may have suggestions
ModeratorOn this Forum tool, search only works at the TinyG level.
Back up to tinyG and a Search box will appear, search on: cartesian.
You will find several old items on topics similar to yours, although I don’t recall them addressing homing.Also have a look at
Riley hacking about, in 2011
I don’t recall how any of those projects worked out in the end.
You seem to be headed into a very “non-standard” space, both FW and HW, relative to the tinyG design model.
The HW and FW flexibility of G2 might be better suited to your project.ModeratorDue/G2 is a superset of tinyG, so any CAM that supports tinyG would support G2.
Their are proprietary Machine centric CAMs that interface G2, probably not what you are looking for.
I have never played with GRBL, have always thought of GRBL as a Machine layer, like tinyG, speaking Gcode plus a few machine specific commands.The G2 wiki should help,
ModeratorGood, you are in business.
I was going to suggest your provide a parameter list ($$ report) on a cloud drive with URL; that frequently reveals info and provides a lot of info about your setup.
Good luck with your machine.
ModeratorWe see very little traffic on this Touch Plate here on this forum.
I have seen quite a bit over at Chilipeppr,and also on the Ox forum,
Even if you have a different machine, the discussion might be helpful.
Touch Plate is usually considered a CAM layer routine, built on tinyG (G2) primitives.
There may also be some very specific items atrelated to the di5/di6 issue.
Good Luck!
Moderator$zmax=1 does set top of z as home, which is the design assumption in tinyG.
There seems to be a pervasive confusion between the use of the switches for limit and homing.
Correct observation.
When I hit machine home, I want it to go to z=max, x=0, y=0 in that order.
That is what tinyG implements.
Calibrating to a touch off plate is a totally different operation in my view.
Touch Plate is a CAM (e.g. Chilipeppr) function, not a motion control function, although some tinyG primitives can be used to implement Touch Plate routines.
Keep in mind that a machine zeroed to the material surface (via touchplate) is no longer “homed” by tinyG definition.Moderator“Calibration” issues are likely belt stretch/tension.
Arc bugs remain in FW, have been there for a while.mm node (not inch) works better, but if problem persists, best solution is to send Gcode that does not contain arcs.
ModeratorFlashing LEDs at least mean that tinyG is Powered.
The flashing LEDs likely mean you need to reload tinyG FW.BUT, as I said earlier, tinyG FW is not required for a COM port to appear in Winx.
Get over that hurdle, then see whats whatModeratorI am looking mostly at your parameter set.
I see $1tr=1.25mm, so your “g1 f400 x50” should be causing the X motor to make 50/1.25 revolutions.
A “g0 X50” command should move at 800mm/min, twice as fast.The parameter set has $_pm = 2 for all 4 motors, which is very typical.
It says when you command any motion, all motors energize to hold their position if they are not generating motion. The buzzing you are hearing is the hold current being pulsed to the motor windings. The fact that you can’t turn them by hand while energized says that at least some of the windings are wired correctly and active, I believe.
$mt=2.0, so the motor leds should stay on for 2 seconds, then you should be able to manually turn the motors.Setting $4pm=0 should turn off the led for motor 4, which you don’t have connected
The jerk parameters are on the low side but I don’t think they should cause no motion to happen. More typical values would be $xjm=5000 and $xjh=10000, same for Y. Optimal values really depend on your final machine configuration. These parameters are for a screw machine at 1.25mm/rev on X and Y.
I agree with Zootalaws, turning the power adjustments all the way up on M1-M3 would not damage anything (be careful, the pot can be damaged with too much screwdriver torque). Running full load current running a real milling job generates a lot of heat so fans blowing on tinyG are desirable. Unloaded motors require very little current to move.
Be sure to monitor your 24V supply while the motors are active for the 2 sec hold interval. It is possible that the power supply current limiter is kicking in (typically an adjustment on the power supply). If you need more time to measure, set $mt=5.0 and restart tinyG.
ModeratorAll I can really discern so far is that you are a Windows user (reference to COM port).
Have you powered up tinyG? What leds are on, off or flashing?
If you are coming from another Arduino based environment (Uno, DUE, etc) be aware that tinyG is not powered via the USB cable.
Don’t get lost in the info on tinyG FW download, etc, quite yet anyway.
The USB terminator on the tinyG, that manages USB details and should cause tinyG to appear as a COM port to your PC, is hardware, not FW on the tinyG device. All you should need to bring up the COM port on a Windows PC is a powered tinyG and a good USB cable.
Until you see the COM port on plugging in the tinyG USB cable, focus on the Windows machine – driver install.
If you have a Win10 machine around, try plugging tinyG into that to see if the COM port appears. To best of my recollection, Win10 was FTDI enabled out of the box.
I’ll assume you have found the wiki at
ModeratorI’ll leave it here for others to find on search.
Yours is the first confirmed bad DUE I have seen, lucky you!Good for others to see your troubleshooting process.
ModeratorDetails and Theory behind the motion planning subsystem are beyond the scope of this forum.
Check out the Wiki atand watch the chatter at
ModeratorI am going to assume you mean your tinyG is in a state where SpnDir flashes constantly after powerup or reset button and cannot be re-programed vi the avrdude based tools.
That would indicate that your bootloader has been over-written.
The most common cause is sending a binary file to tinyG rather than a Gcode file to tinyG. If the binary file mimics a FW download, which is statistically possible(if not probable), that binary file gets written to tinyG flash.Solution is to reprogram tinyG with an Atmel ICE or to send the unit back to Synthetos and they will reflash it for you.
ModeratorI’m having a bit of difficulty understanding your terminology.
Here is what I think I see:You have a ‘known good’ Gshield that works with Uno and perhaps GRBL(?)
You connected the Gshield to a Duo, flashed the Duo with firmware $fb=78.02 downloaded from somewhere. That is a bit confusing, since the Gshield fw at
is $fb=78.03 , ??
Where did you get $fb=78.02 ?You are using Coolterm to interface with G2, that start up response looks OK.
What pins are you referring to when you write “there are no changes in the digital pins.” ? Are you measuring at the inputs to the Gshield stepper drivers? H
ow are you measuring, Multimeter?
Difficult to see brief PWM pulses on a STEP pin with a multimeter.From your second post, I assume that was a measurement at a Motor Enable pin. Duration is correct, so G2 seems to be running, but you should be measuring logic low for 10 seconds.
Do you have steppers connected to Gshield?
How are you powering Due and Gshield?
Can you dump your parameter set to a cloud file (dropbox, etc.) and provide a URL?
-
AuthorPosts
