Forum Replies Created
-
AuthorPosts
-
cmcgrath5035
ModeratorNope, It is aimed at a higher performance ARM
ModeratorThere has been very limited activity in the past few year on tinyG.
You could post this question here, closer to whatever developer activity there is: https://github.com/synthetos/TinyG/issuesWhile there, have a look at the G2 project at https://github.com/synthetos/g2
g2was the next generation, might be a better fit to your needsGood luck with your project
ModeratorJust a thought – I see that M30 resets to $gun default setting, G20 or G21
Any chance your job runs in the “not default” measurement system?
ModeratortinyG was born perhaps 8 years (or more) ago and focused on the DIY build your own 3 axis machine, which morphed quickly to 4 motor three axis machines. Many basic kits came out with no limit switches at all, then larger, more rugged designs came along as well. Any tinyG was used in many 3rd party machines.
Make sure you read this wiki item carefully
https://github.com/synthetos/TinyG/wiki/Homing-and-Limits-Description-and-OperationSummary: G28.2 is hard coded to home to Zmax if it is enabled. It will not home to Zmin. If Z homing is used, Z home must be Y=0 and all z motion down must be negative. these are the assumptions used in tinyG.
G2core has implemented some flexibility. I believe (I am not a developer) the decision was made to minimize Z homing that dragged across the work piece.
ALso read theru https://github.com/synthetos/TinyG/wiki/Gcode-Support, see if your interpretation of G30 is same as Synthetos.The Zmin switch, or Zmin input, is also used for automatic probing of the work piece.
Good luck with sorting this out, as you say it may just need a procedural workaround.
ModeratorOK, the original step 6 typo comment confirms what I suspected and makes sense.
And I’ll paraphrase that your job is programmed to return the machine to Machine zero, not the offset zero established by step 4. You could have asked why you needed to issue the rehome twice.
I need to add that this is the only discussion I have ever been involved in where a Zmax switch was actually implemented by the user. So , while unlikely, we may be dealing with a 5YO (probably more) that has never been seen.
I’ll bypass most of my usual questions about the set up and parameter setting. You are running FW 440.20, I assume?
A couple of possibly helpful debug questions
A. After the job runs (Original step 5), where does the machine think it is in offset x,y,z space? Is that location what your programming expects?
B. Does a $$ parameter dump reveal anything odd when run at this point?
C. After checking location, try manually jogging up to a safe Z height, then issuing just a G28.2 X0 Y0Moderatora resend to make sure I get notified of a response
ModeratorPlease clarify what command you are entering at Step 6, I am not familiar with a G20.2 ? Perhaps that is a typo?
Also, confirm that you have you limit switch on Z at the top of travel, presumably near the mechanical top of travel . I think of most questions in the context of a 3 axis gantry machine, you might have something very different.
And describe your jog in step 3, do you jog the Z axis? If so, seems Step 4 would change Z0 to a setting not at the mechanical Z0 which could explaining step 6 hitting the mechanical Z0 switch.
March 1, 2023 at 8:58 pm in reply to: Configuring interlock & GRBL pins on Arduino DUE & G2core #12160ModeratorThis is likely a software/configuration issue, but yes, the endresult is hardware that works.
I recommend you post thas at https://github.com/synthetos/g2/issues, the G2 developers and many other hackers/customizers hand out there.
You make the shield in your design sound somewhat mysterious, home brew?
If it is a commercial part, identifying might speed a response.Good luck with your project
ModeratorManually jog or move your spindle to the center of your workspace and reset to establish a (0,0,0) position
The Move the spindle with a G0 command to X=20 and Y=20 (mm).
Now issue a Zero X axis command.
The Machine should first rise to your Z safety distance setting, then move in the negative direction toward X=0. After a short move, manually operate the X limit Switch and observe if the zeroing sequence begins.
Likewise with Y.Be ready to kill power if strange things happen
ModeratorYou will not find exactly what you are looking for here at Synthetos.
Very early work on a version of what you might be looking for, the tgFX GUI, was put on the shelf when other projects like Chilipeppr and CNCJS got started.
If you scour the tinyG issues pages at https://github.com/synthetos/TinyG/issues you will see others like yourself working similar issues in both open and proprietary space.
Much of the intense work on Chilipeppr and CNCJS dropped off several years ago but the code is available for viewing, cloning and extending.
From your description of the task, it would appear to me that you are familiar with all the resources on Github and the Synthetos Web.ModeratorHmmm, I don’t see any new topic in ‘TinyG Support’
I am also not sure what your comment “awaiting moderation”, are you getting some sort of message that requires some sort of approval or other interaction ??
ModeratorYou are likely thinks about a 3D printer type application. TinyG will do whatever the G code tells it to do, but all motion will be subject to the jerk motion enhancement that seeks to maximize machine efficiency (time spent on the job). Some folks have used the A axis to coordinate some variation in extrusion rate.
You may want to research the G2 project somewhat, it is aimed at providing the motion foundation for 3D as well as 2D motion.
https://github.com/synthetos/g2/wiki
tinyG is rather resource limited (memory, CPU).ModeratorIt has been a long time since I played with parameter setup and do not have a current hookup to refresh on.
I do recall a situation where a parameter default change in value needed to be followed by an immediate tinyG hard reset.
Are your trying to use $ex=1?
I did in the beginning (6 years ago) but it fell into disfavor – due to poor device driver implementations of the protocol.$ex=2 is the preferred if you are not using a system such as Chilipeppr which manages flow based on buffer fill.ModeratorI have no experience with GRBL-GRU and very limited with UGCS. Most of my work has been with Chilipeppr or CoolTerm, and occasionally via a Linux putty terminal. I have over time had folks attempt variou bulk loading schemes for setting parameters that resulted in erratic behavior. defa=1 was a recovery mechanism. The root of the issue in those cases is a hardware bug in the tinyG micro controller-EEPROM interface, which is patched by shutting down the serial reader interface while an EEPROM write is being performed. Manually entering parameters one at a time via a CLI is OK, bulk loading needs to be properly implemented to ensure all data is properly written.
In Chilipeppr, code in the SPJS properly handles this.
In this item https://github.com/synthetos/TinyG/wiki/scripting-settings
a 40ms delay is suggested. I have seen delays as much as 100ms. Up to youModeratorI love it when someone solves their own problem, especially when I have to think hard about where to go next.
First, here is a link to the 4 pages of tinyG Schematics, which might come in handy
https://github.com/synthetos/TinyG/tree/master/hardware/v8schematics/v8hOn Page 1 you will see the RTS and CTS pins on the FTDI devie(USB<->Serial)
FT230X. Probably not an issue if you stick with the Pico, be aware that the
ATxmega192 device is 3.3V logic and has little tolerance for 5V signals.Also note that the serial receive path from J14 is wire-OR’d to the FTDI device with each path having a 2.7Kohm resistor. You might want to research how RTS and CTS logic operates and implement similar isolation.
It is not obvious where you plan to end up with flow control strategy.
The most successful implementations (Chillipeppr, cncjs) use tinyG input buffer fill for flow control, obviating the need for rts/cts connections.Good luck with your project!
-
AuthorPosts
