Forum Replies Created
-
AuthorPosts
-
cmcgrath5035
ModeratorBTW, what $fb= ?
If you are off into tinyG2 EDGE space, this may need a different debug tact.
Any build > 83.09 might be suspect.
Have you tweaked any tinyG2 code?And also, I now recall you are using external stepper drivers. Have you researched compatibility between tinyG2 and those.
Specifically, 3.3V logic and step pulse width?
You mentioned early on 6 pins for three motor drivers, presumably step and direction.
How about enable?
If you leave motors constantly enabled, not they get sort of warm?ModeratorWhat OS are you flashing from (Win, Mac, Linux)
What method to upgrade (reflash) did you use (CLI, SPJS, other)?Unfortunately, your results are now very similar to two other active Forum items, cause not yet well understood(by me, anyway).
The devs looking hard at it
While I have your attention, do you recall if you had specified any of the Gcode overrides on your job, such as speed up/slow down?
ModeratorIt will take me a bit to look at your files – I am on the road.
I am not surprised you were able to bend bolts – your drive set up does look a bit “torquey” :).Does the CP DRO (digital read out) say 0,0 but the position is off, or does the DRO report an accurate, but incorrect position when you send it to G54 zero?
TinyG does not intentionally change G54 zero. If G54 offsets (from G53) are (0,0), then position drift in spindle position relative to G53 (0,0) could be caused by (in no particular order)
1. Stepper slips
2. Belt or drivetrain slips – are your stepper to LEAD screw couplings tight?
3. Rogue changes to the G54 x and Y offset parameters
4. Gcode commands that tinyG cannot interpret/sees as error.
5. Other……Most reason 4 errors seem to be related to G2 and G3 ARCs, if you can regenerate Gcode without them and things work better, that could be useful input.
ModeratorPlease report what FW you had running tinyG (440.20 is most recent) and what version of SPJS.
You are the third in the past few days with this, starting to look like more than a random issue.BTW, as you probably know, the flashing SpinDir means bootloader is running, with nothing to boot into.
-
This reply was modified 8 years, 9 months ago by
cmcgrath5035.
ModeratorOn two cut jobs the router did something unexpected. On one file with two depth cuts, it “forgot” to do a couple of the cuts, and on another file, it did a random move diagonaly and rapid across the work without raising the bit which ruined it. I have run the code in several simulators, no issues. Thinking maybe something in the file is not supported? Can chiliperr send code “too fast” for the TinyG to keep up with?
I assume you are focused on the “forgot” to do a couple cuts and the ranom move diagonally… comments.
Both could be symptoms of issues with tinyG’s interpretation of the Gcode into machine movement directions, particularly relating to arc commands (G2 and G3 Gcode commands).
Unfortunately, simulators do help your visualize Gcode directives, but there are many ways for simulators to make interpretations of Gcode that are not or cannot be implemented by tinyG.Suggestions: Review this:
to get an idea of some of the Gcode commands that are not implemented or fully supported.
Also, please confirm that you are running the latest FW, 440.20.
While likely not in play here, have you run enough basic Gcode to verify the dimensional accuracy of your machine’s settings. e.g. when commanded to trace a 6.5″ circle, do you get a 6.5″ circle?
It will take some time to analyze your Gcode. In the meantime, I believe CamBam has an option to use only short linear segments, no arcs. You could try that to see if it performs more accurately for you.
To your final question above relative to ChiliPepprb overrunning tinyG; that is doubtful. ChiliPeppr, and SPJS specifically, are designed around a buffer fill algorithm and strategy that aims to prevent overflow while keeping tinyG “fully engaged”.
ModeratorOn two cut jobs the router did something unexpected. On one file with two depth cuts, it “forgot” to do a couple of the cuts, and on another file, it did a random move diagonaly and rapid across the work without raising the bit which ruined it. I have run the code in several simulators, no issues. Thinking maybe something in the file is not supported? Can chiliperr send code “too fast” for the TinyG to keep up with?
I assume you are focused on the “forgot” to do a couple cuts and the ranom move diagonally… comments.
Both could be symptoms of issues with tinyG’s interpretation of the Gcode into machine movement directions, particularly relating to arc commands (G2 and G3 Gcode commands).
Unfortunately, simulators do help your visualize Gcode directives, but there are many ways for simulators to make interpretations of Gcode that are not or cannot be implemented by tinyG.Suggestions: Review this:
to get an idea of some of the Gcode commands that are not implemented or fully supported.
Also, please confirm that you are running the latest FW, 440.20.
While likely not in play here, have you run enough basic Gcode to verify the dimensional accuracy of your machine’s settings. e.g. when commanded to trace a 6.5″ circle, do you get a 6.5″ circle?
It will take some time to analyze your Gcode. In the meantime, I believe CamBam has an option to use only short linear segments, no arcs. You could try that to see if it performs more accurately for you.
To your final question above relative to ChiliPepprb overrunning tinyG; that is doubtful. ChiliPeppr, and SPJS specifically, are designed around a buffer fill algorithm and strategy that aims to prevent overflow while keeping tinyG “fully engaged”.
ModeratorThe only documentation I could find requires the programmer to read the bits
ModeratorNice looking machine!
I had audio off, perhaps the “need” for Ymax homing was apparent there.
Since you have a custom implementation of a classic X-Y-Z milling machine,
it is not obvious why you need to home to Ymax, unless it is just to move the gantry away from you when homed.My read of the G28.2 homing cycle command is that is finds Y home by searching in the negative or “move from positive toward zero” direction until it finds the limit switch, then backs off and sets Y=0 at that point. My further interpretation is that when homing Y axis, only the Ymin port is being monitored by the hardware.
That may be incorrect on my part, I have not played with homing yet.FET circuit – If Interpreted correctly, you are using the FET as an inverter, gate controlled by output from prox switch. So if the prox is NC, you invert it so tinyG2 sees a NO switch. You might want to consider a resistor pull-up(2.7K?) on the port pins (to 3.3V), I believe the on-chip pull up on the DUE is rather high impedance. And maybe a 0..22uf to ground, for noise immunity.
That would be similar to how tinyG conditions ports
Can you please report the FET specifics you are using (device code)?
Someone reading may wish to follow you lead.Moderatoronly thing i haven’t tried is using a atmel programmer as i don’t have one… do have a mini adafruit programmer jobbie but i don’t think that’ll work with the chip on the tinyg…
I asked the tinyGupdater dev to look at this thread.
I believe he is working on a fix for this situation, has a Win64 beta that might help.ModeratorOK, good luck and please do send along your switch interface solution when complete, many folks are using these prox switches.
I do suggest you test homing the X axis by itself first, that should work.
Not clear to me how you can Home to Ymax or what you will end up with as a Y coordinate. TinyG is homing is ‘hard coded’ to Ymin, not sure if that is changed in tinyG2.
Moderatornope never tried updating through Raspberry… plugged the tinyg into my winx64 machine via usb and used avrdude. i get exact same behaviour as KingBubbaTruck describes. also tried -e in command line with no success. gonna try updating using my mac… though i doubt it will make a difference…
and hey thanks for trying to help…Please be a bit more specific (I am gathering data here)
On Win64, you attempted to flash from a CMD window, using avrdude from arduino dev environment? Or describe
On OSx, you used the tinyGUpdater app from Synthetos web? or ?
This looks like a fuse issue, for which a solution may soon be available (being worked by devs), this info may help.
Have you done FW updates successfully in the past?
It is not at all clear (to me) how fuse state could be changed.ModeratorOK, you were running tinyG 440.20.
Now you have a constantly flashing spinDir LED?
That means bootloader is running
You then tried to reload 440.20?
And your did that using the SPJS 1.86 on RasbPi FW upgrade process?
And then your saw the verification error?BTW, no obvious reason WiFi connection to SPJS would be the issue
ModeratorAh so, more input.
Also another important detail i am not using a gshield board just the pinout.
I am unable to use gshield because the motors and size of the machine require 4.2 amp steppers. so currently i have 6 pins in use for step and direction. 2 more for spindle pwm and enable. and the remaining 3 for Xmin Ymax and Zmax.First , my bad, I started thinking you had tinyGV8.
I am not sure what Gshield has for pull-up conditioning, if any.
I do not believe the DUE has anything either, just raw access to the I/O port.So now I am confused again, did you mean Xmin, Ymin, Zmax?
ModeratorThe limit switch signal reads 0V when no metal is put in front and 12V when metal is if front.
That sounds like NC to me.
But, then, why did a grounding wire change anything? switches should be NC state (if away from metal).
???I do hope your voltage dividers will keep voltage at tiny G inputs <3.3V.
Otherwise, quick death. A better interface for these switches is a diode allowing switch to pull tinyG input low but blocking the high voltage from switch. I’ll try to dig up the schematic.ModeratorYou are perhaps the first mention of program Camworks; so you are not asking any seasoned veterans here.
Can you provide a URL for the product?
Is there a particular reason you chose Camworks over other options?There is no standardized definition of the functionality of a post processor.
Waiting until the ‘post’ phase to remove unsupported Gcode commands should probably be in the core, not post phase.I will guess that, if the authors of Camworks are even aware of tinyG, the chance that they have read the wiki and accommodated what is and is not supported in tinyG is rather low.
-
This reply was modified 8 years, 9 months ago by
-
AuthorPosts
