Forum Replies Created
-
AuthorPosts
-
cmcgrath5035
ModeratorGood to know.
We don’t hear from many MAC users.ModeratorI tried reproducing your Gcode as .csv results.
I run Linux and Chrome.
When I use the Download/Save G Code option in the TinyGWorkspace widget, it downloads the Gcode to a file named ‘download’ with no extension to my default Chrome downloads directory.Were you using Windows or Mac when you downloaded the Gcode file?
Seems odd that an OS would see Gcode as csv. There are not many “,” in Gcode files.
Or did you use some other method to extract the Gcode files?
ModeratorMy mm comment – probably what you are attributing to pen mount backlash.
Very helpful dataset, I like your backlash test line.
I’m not sure how/why Gcode files are Gcode.csv.
Did Chilipeppr output them that way?
Gdrive viewer put .csv into a spreadsheet column, sort of hard to readParameters look OK.
Vmax on X and Y rather fast (50000, vs 16000) .
If you had a heavy spindle attached, GO moves could slip if belts were not real tight, but you observations are with very slow G1 or G2 moves, so I don’t think Vmax in play here.We have seen, off and on, inch mode Gcode having this issue with fw 440.20 (and earlier).
Your are the first I have seen someone actually output the CP inch logo to the machine in quite a while, I am a little surprised this basic test tool is failing and it hasn’t appeared frequently. It could be somewhat Ox related – Ox uses larger GT3 pulleys, resulting in $xtr=60mm.
Most test beds have been using SO2 parameters, where $xtr=40mm.So, for now, treat inch mode as buggy.
Use mm mode.Please keep your Gdrive dataset up, I will pass it on to the devs as a test case for getting this resolved.
ModeratorTo me, I see issues in your mm plots as well.
Copy your parameters ($$ dump) and Gcode to a cloud drive, post links.What sort of machine?
What OS you run?
ModeratorIf you are familiar with Python, have a look at this Forum item
ModeratorYou are developing your own parameter sending software, I am guessing.
I am also guessing your are sending commands too quickly.
Have you reviewed this :
?
Flow control (Xon/Xoff, RTS/CTS) no help here.
The best way is to send a command, in text or json mode, then wait for response from tinyG that the parameter write is successfully completed. I have seen parameter write delays as long a 100ms.
Folks who don’t want to code a closed loop solution claim waiting 1sec (1000ms) between sending parameter updates usually works.February 25, 2016 at 3:40 pm in reply to: Home command erratic behavior: ypos changes to bad value #9376ModeratorI’m using windows 7 on a laptop, coolterm for sending settings and gvim for editing files. I’ve played a bit with CP and Inkscape, but haven’t got to the point yet where I need them.
CoolTerm and Vi are a good base to start from.
Chilipeppr has some enhance probing widgets you may want to play with in the future.
I would fix $yjm and Maybe try $xjh=$yjh=1000 as well to start.
Unclear to me how jerk and relatively low travel per revolution might interact. For comparison, NEMA23 belt machines have $tr between 40 and 60February 25, 2016 at 6:53 am in reply to: Home command erratic behavior: ypos changes to bad value #9373ModeratorIn future, please post big files like $$ dump to a cloud drive and provide a link.
This is a rather new tinyG setup fo me.
Are you following a guideline somewhere – how did you select these parameters?
The appear to be more or less OK, but very different from the typical belt machine.The CS website no help – focus is on their controller
What OS and software do you use for communicating with tinyG?
I think $yjm is wrong (1 vs 1000), just a guess.
Not at all clear why you have $yjh=10000 but $yjm=1 (but likely you wanted 1000).
$yjh is Yaxis jerk during homing.We see few screw machines like this, so may need to iterate settings a bit.
February 22, 2016 at 11:34 am in reply to: TinyG with external drivers: J19 (motor3) and J20 (motor 4) don't work #9370ModeratorOK, good info to have on results with $tr=40.
Are you back to $fb=440.20 ?$fb=412.01 is quite outdated.
This thread will do for now, I believe. Hopefully the devs will stop in and comment.
February 21, 2016 at 5:58 am in reply to: TinyG with external drivers: J19 (motor3) and J20 (motor 4) don't work #9368ModeratorSince you have obviously done your homework, you probably seen these items
There has not been much step pulse width discussion since the days of FW 438.02, when Alden reworked some internals to get PWs in the 4-5us range and commented (I can’t find that) that due to hardware limitations, that was probably all we could get.
Of course, you are not getting 4-5us across all drivers.You parameters look OK to me (I do a ‘diff’ between yours and a ‘known work OK’ set to highlight differences to look at).
One oddity in this parameter set – you have all four channels set to either $_tr=5 or 1.25mm. Unusual values for belt machines. I assume you did that for testing purposes, or perhaps you are targeting a large (based on $_tm values) screw machine.
If you rerun your test with all $_tr=40mm (GTX2 belt typical setting), get same results?
You could be identifying an issue with uniformly low $_tr values; I would guess most testing is done with belt machine parameters that might have just one(the Z axis) in the $_tr value in the 1-2mm range.I have asked the developers to stop by here for a look as well, I am sort of out of ideas and useful info.
ModeratorIf you are familiar with Python scripting, you may want to review this parameter downloader:
It may provide some hints.
ModeratorShort Answer (all I have time for at the moment, but good question)
1. Review all the wili write ups on status reports, start with this one2. If that does not get you an answer, post a question here:
while you are in the issues area, look around at open and closed threads, may have been answered but not made it to the wiki yet.
If you do solve this, please report here for future lookers.
ModeratorGood thing you didn’t directly post Matlab, as I have not programmed using it in perhaps 20 years. So your description much more helpful
Are you aware of, and ensured, that the implications of this Wiki section are accomodated in your code:
On the chilipeppr side, we have determined that the best, and perhaps only way to make the bulk programming (multiple parameter) writes is to send a single parameter value, or multiple parameters via a json as you appear to be doing, then wait until a confirmation is received from tinyG before sending anything else. Both the configuretinyG widget and the ArchiveandRestore widget (see:
) use this methodology.
You cannot rely on software flow control (I assume that means Xon/Xoff) to help here. I will also observe that I have seen individual parameter write cycles take 80 to 90ms, not <30ms, with a lot of variation.
Folks who try to just dump a serial stream of parameters without watching the response channel typically wait a real long time, 500-1000ms, between parameters and claim success.To make matters worse, there seems to be evidence that jamming the channel with too many parameters and or too fast can corrupt other, some hidden, parameters in EEPROM. So doing just a read back of what you think you wrote is not adequate either.
At the moment, the configuretinyG widget seems to be misbehaving and I am recommending that folks avoid it. We do not have a clear diagnosis.
ArchiveandRestore, which uses the same return check mechanism, still works for me. A (major?) difference is that ArchiveandRestore sends parameters one at a time.We are way down in the weeds here, and may need to go deeper.
I'll pause and get your feedback on what is already here.
February 19, 2016 at 8:30 am in reply to: TinyG with external drivers: J19 (motor3) and J20 (motor 4) don't work #9362ModeratorThat is odd, indeed.
Can you describe your setup a bit?What firmware are you running?
How do you set up and run your tinyG? (CoolTerm, ChiliPeppr, other)?
Maybe post a $$ parameter dump to a cloud drive and provide a linkFebruary 18, 2016 at 7:05 am in reply to: TinyG with external drivers: J19 (motor3) and J20 (motor 4) don't work #9357ModeratorLook closely at your tinyG board and find what release version you have.
somethin like tinGV8j, or V8k, etc.
The schematics can be found herein pdf format.
What you will see is that J17-J20 are simply pins tied to the on-board driver device inputs, they are not unique to the external interfaces or uniquely addressed in FW.
If only one board behaved this way, it could be the board but since both do, something else is in play.
What do you know about the input side of your external drivers-
Are they opto-isolator inputs(many are)?Did you try J19 and J20 with the 3.3V to 5V level shifters?
I have seen some opto-isolator inputs that were marginal with 3.3V drive.
You might even find that a buffered (higher current capability) 3.3V signal would work.Do the green leds for driver 3 and driver 4 on tinyG flicker when you send movement commands? They should, even with no motor attached.
Are you sure you have the drivers enabled? $3pm=2, $4pm=2 ? -
AuthorPosts
