Forum Replies Created
-
AuthorPosts
-
alden
MemberIf you like I can take a look at this (probably sometime this afternoon, US EDT) before you start messing with it. I don’t know what would work without studying it. I believe there are some subtleties regarding the FTDI chip. Also, If something blows up, I have other boards; you don’t (but we would appreciate your business 🙂
– Alden
MemberIt’s actually a good idea to use the USB 5v, it was just not part of the design. The 5v is actually regulated down to 3.3v for use on the board. The RS485 adapter uses 5v directly, but the rest is all 3.3v. The total current draw is about 100ma, which is well within the limit for USB. It’s a good idea we should consider in any future hardware revs.
Member4.2 Amps at 24 volts for those motors should be just fine.
– Alden
MemberJan, I’m glad your boards have arrived. We are not getting your email – I do not know why. Please use this thread to communicate. We do watch both the forum and the email stream carefully.
– Alden
MemberIf you wanted to set the Z axis to no 1x microstepping you can simply ground the Z axis USM0 and USM1. The resistors are on the board for convenience of changing the microsteps, and could be zero ohm resistors. The USM lines can be tied to hi or lo directly without the need for a resistor.
I would also look at the documentation on the the TI DRV8811 driver chip you can find here:
https://github.com/synthetos/grblShield/tree/master/referencesRefer to page 11.
MemberI’m not sure how easy this is. I can direct you to the schematics for the v2 grblshield here:
https://github.com/synthetos/grblShield/tree/master/hardwareIt would involve cutting and jumping a bit., Are you interesting in a different Z than X and Y? You could leave X and Y alone (or change the jumpers), and disconnect Z and wire it in separately.
MemberThanks for the support. Check the wiki for limit switches here for hardware:
http://www.synthetos.com/wiki/index.php?title=Projects:TinyG-Hardware-Info:#Interface_Pinoutsand here for configuring the switches:
http://www.synthetos.com/wiki/index.php?title=TinyG:Configuring#Axis_SettingsPlease be aware that even though the pinouts are broken out by axis, currently any switch will fire a homing or limit operation. So technically they could all connect to a single pin. Also, the switches are Normally Open operation. There are plans to make this more sophisticated, but for now it gets the job done.
There is actually no such thing as eStop, as a real emergency stop would have to cut power to the motors, and the controller board (TinyG) cannot do that. But you can reset the board by using the reset button. These are not brought out to any pins, however. You can force the reset in software by sending the board a control-X character.
Alden
MemberSecond that! Really nice work.
– Alden
MemberSo I’ve set up a real Windows environment with Windows XP Professional version 2002 Service Pack 3 and tried to reproduce the issue, but unfortunately the Windows setup runs without a hitch. I am using the latest FTDI VCP drivers (version 2.8.24) – which may be newer than yours, and CoolTerm Win 1.4.0 (build 157) – also the latest version. I can run the entire Shapeoko file on Crocs build 326.06. I am also running a TinyG config that is identical to yours except that it seems all my motors run in the opposite direction from your so the polarity settings are all different.
So lets try to figure out what’s different in the setups.
One thing I noticed was that you are running the Shapeoko with VERY conservative configuration settings. It’s capable of moving a LOT faster and being a lot more responsive. Below is a comparison of what I’m running for TinyG on the Shapeoko.
– You have Motor 1 (X axis) set to 1.8 degrees per step. Motors 2 and 3 are set to 0.9 degrees per step. Is this right? Seems they should all be 1.8 or all be 0.9. My settings are 1.8 degrees per step (200 steps per revolution).
– I measured 34.5 mm per revolution, you have 35. You may be right., I need to check my measurements.
– As I mentioned earlier, our polarities are different, but this should be of no consequence. I assume you already know that is the convention for the X axis to move positive to the right, for Y to move positive away from the front, and Z to move positive upwards.
– Your Seek Rate (which has been more accurately renamed to “Velocity Max” in 0,93) is set to 12000 mm/min for the X axis but is 600 for Y and 500 for Z. My settings are X=16000, Y=16000, Z=1200. These are admittedly very fast, and may require some mechanical tweaking to achieve. A good starting point would be 10000, 10000, 1000 until you are sure these work for you.
– Your feed rates should equal your seek rates – at least for testing. If you run some heavy material through the machine you may want to drop these to a speed where you still get good cutting. This may vary from job to job depending on the material you are cutting. The velocity max should not need to change.
– My Jerk max values are 5 billion – you have 50 million. This makes a huge difference in acceleration speeds. If you get stalls, back off from this – try 2 billion, or less
– My junction acceleration is 200000 – you have 50000. The related value: cornering delta (renamed “junction deviation” in 0.93) is the same as yours at 0.05 for all axes
The rest is probably fine. You will get much better performance from the system with different settings. But first let’s figure out the immediate issue.
– Alden
MemberMike,
Thanks for the detailed report. What your symptoms suggest is that it’s most likely the serial stream is getting corrupted, and this is most likely a problem in the end-to-end operation of XON/XOFF. What the machine does after the serial stream becomes corrupted is quite random and unpredictable, so not much information there.
I (re)confirmed that I am able to run the shapeoko hello world file you provided on my setup. It runs successfully. I also confirmed that you have XON/XOFF enabled from your settings. You do. So what this tells me is that it’s probably not a problem in the TinyG code, but in the upstream serial interface and/or driver.
There are some significant differences between our host environments:
– I’m running MacOSX Lion, you are on XP.
– I’m therefore running a completely different set of FTDI drivers than you are – you are running FTDI driver version 2.8.14.0
– I’m therefore running the Mac version of Coolterm not the Windows versionSo over the weekend I’ll try to replicate your setup as closely as possible on a Windows box I have lying around. Some questions:
– What kind of machine are you running?
– Do you have any information on the serial port and the serial drivers. See
My Computer/Control Panel/System/Device Manager/ Ports for info.
– What service pack are you up to on XP and what type of XP are you running – home? pro?
– What version of Coolterm are your running?
– Just for yuks, what COM port does your USB driver map to (although this is usually quite random)?– Lastly, what is the behavior of the XON/XOFF LED? It’s the OUT3 LED located right next to the resistor labeled R22 in the picture here:
http://www.synthetos.com/wiki/index.php?title=Projects:TinyG-Hardware-Info:#Interface_Pinouts— Does it flash on and off during operation?
— When the machine goes OC is it on or off?
— Does it not turn on at all?The LED turns ON when XOFF is issued by the board (because the serial receive buffer hit it’s hi threshold -about 200 out of 256 characters), then turns OFF when XON is received from the host. Being stuck in the ON state can indicate that the board received characters, hit the hi limit of the buffer, issued the XOFF, then never received an XON. What THAT usually means is that the host never acted on the XOFF and just continued to jam characters down the wire.
I’ll reserve judgement until we confirm or eliminate XON/XOFF as the culprit, but we are finding that even though our setups work fine with XON/XOFF, some others don’t. Rather than diagnose each XON/XOFF problem independently the tgFX code synchronizes on the command responses rather than relying on XON/XOFF. So bear with us a bit longer until we get that out. In the mean time, let’s try to get to the bottom of your issue.
– Alden
UPDATE: Can you please confirm the release of the FTDI Drivers you are running? in the VCP driver section I only see version 2.08.24 for for the Windows x86 – 32 bit. I do not see any drivers labeled 2.8.14.0 – perhaps you are running an earlier version.
Also, please also confirm that you are using the VCP drivers and not the D2XX drivers – I have to assume that you are because otherwise you don’t get a COM port, but let’s just be sure.
Thanks
MemberI am intending to put this on the wiki, as the question has come up more than once. A few pictures would also help. I wanted to get this to you so I figured it could originate in the forum.
As for your project, I think either solution would work, and the grbl solution is less expensive. The acceleration difference come into the picture when you really try to push the speed envelope, which it sounds like you don’t need to do. The adaptation of the Z axis also sounds manageable if you are willing to pre-process your G code. Just set the Z travel to some known value and emit code that gets the right amount of rotation.
Alden
MemberIt is a good question, and one that should have a good answer. So please bear with this lengthy post. I’m not going to argue about which is “better” – we are heavily involved in both projects and want them both to be successful.
Basic similarities between grbl+grblshield and tinyg:
* Both basically support the same set of Gcodes – with some minor differences. refs:
https://github.com/grbl/grbl/wiki
http://www.synthetos.com/wiki/index.php?title=Projects:TinyG-Gcode-Support
* Both adhere as closely as possible to the NIST Gcode spec. refs:
http://www.isd.mel.nist.gov/documents/kramer/RS274NGC_3.ps
http://technisoftdirect.com/catalog/download/RS274NGC_3.pdf
* Both implement enhanced CNC features such as homing cycles, feedhold (!) and restart (~ , aka cycle start) and software reset (control-x)
* Both use Texas Instruments DRV8811 stepper controller chips
* Both are written in C, GNU GPL open source licensed
* Both projects are currently in betaSome fundamental differences are:
* grbl is an XYZ 3 axis controller (i.e. a cartesian robot). TinyG is a 6 axis controller that runs XYZ and also ABC rotational axes. Many of the difference are attributable to this fact. See the NIST spec (above) as to how rotary axes work, or refer to the discussion on the TinyG wiki on rotational axes:
http://www.synthetos.com/wiki/index.php?title=TinyG:Configuring#Rotational_Axis_Settings_and_Modes* TinyG has 4 motors, grblshield has 3. What’s up? It is possible (and common) for grbl to run dual gantry configs – like a dual Y by using 2 stepper drivers attached to the Y step and dir lines. This can present some challenges in homing, but in general this works pretty well. Grblshield only supports 3 axes, and the motors are tied to the X, Y and Z axes. In TinyG the motors are configurable (mappable) to an axis. If you want 4 X axes, map motors 1-4 to X and have a great day. Generally people map the 4th motor to Y the or A axis.
* TinyG runs 3rd order, constant jerk acceleration profiles, grbl runs 2nd order constant acceleration profiles. What does this mean? In grbl the velocity profile during acceleration and deceleration looks like a pure trapezoid in time. For example the move starts at zero velocity, then velocity ramps in a straight line to the target velocity, then decelerates in a straight line back to zero. In TinyG the velocity profile is an S curve that ramps to the target velocity during acceleration and in reverse during the deceleration phase. The means that you can run to motors harder in transition and hence operate at faster accelerations and decelerations. See:
http://www.youtube.com/watch?v=pCC1GXnYfFIIt also means there are fewer machine resonances excited (that cause chatter and other problems) as the jerk term is controlled. Jerk is a measure of the impact a machine is hit with during a velocity change.
* All settings on TinyG are configurable on a per axis or per motor basis. In grbl one parameter applies to all axes (XYZ) – with the exception of steps per mm and polarity – which must be settable on a per axis/per motor basis. A subtlety is that TinyG treats axes and motors as different objects that are configured independently and them mapped together. grbl treats them as the same object – which is fine given its XYZ mission. TinyG does not have that luxury as it needs to support ABC axes which need very different configurations that X Y and Z (to start with, they are in degrees, not linear units…).
Independent control also becomes an issue if the dynamics of the Z axis are significantly different than X and Y, like on Shapeoko where Z is a screw axis and X and Y are belts.
refs:
https://github.com/grbl/grbl/wiki/Configuring-Grbl
http://www.synthetos.com/wiki/index.php?title=TinyG:Configuring* TinyG is designed to be run “from the command line”. Since there are more configuration settings to worry about it offers a set of mnemonics for configuration, machine state and configuration status inquiries. It also offers real-time status reports (DRO-type output). grbl also has real-time status reports in edge right now. TinyG has a set of help screens available from the command prompt. grbl offers some of these features but in general is more “silent”. There are plans to add new features to grbl in future releases, and we are participants and boosters in those discussions.
refs:
https://github.com/grbl/grbl/wiki
http://www.synthetos.com/wiki/index.php?title=Using_TinyG* In addition to command line operation, TinyG implements a JSON interface. This gets pretty arcane, but is useful if you are writing a controller for TinyG. The JSON interface is really a REST interface that implements the objects and verbs in the system. Its different from what people normally think of as REST in that the transport is USB serial, not HTTP.
http://www.synthetos.com/wiki/index.php?title=Projects:TinyG-JSON* TinyG implements a set of embedded self tests to verify proper system operation and assist in setup
* Different embedded processors:
– The processor chip for grbl is an Atmel ATmega328p that runs on the Arduino *hardware*. Note that once you program grbl onto it it is no longer an “Arduino” as you have taken over the chip and it it will not run Processing anymore (until you re-flash it – then it’s no longer grbl) The 328p runs at 16 Mhz, has 32K FLASH memory (program memory) and 2K of RAM
ref: http://www.atmel.com/Images/doc8161.pdf).– The processor chip on tinyg is an Atmel Xmega192A3 that runs at 32 Mhz, has 192K FLASH and 16K RAM.
ref: http://www.atmel.com/Images/doc8068.pdf)The difference in processors means that tinyg can do more computation and have larger firmware and RAM usage. It also means that grbl is programmable using a garden variety Atmel ISP programmer, and TinyG requires a programmer that implements the newer PDI programming protocol – such as the Atmel ISP MKII programmer (at $35 from Mouser electronics. This programmer also works fine on the older protocols). We implemented a boot loader on tinyg at one point (xboot project) but found AVRdude to be so unreliable that we did not release it. We also offer a firmware upgrade service for the cost of postage back and forth, but really if you are interested in keeping up with the project you should get a capable programmer.
The processor difference also means that grbl generates step pulses at a rate of 30Khz, TinyG at 50Khz.
There are a number of other differences such as communications and various system, settings, but this really gets lost in the weeds. Refer to the respective wikis – particularly around configuration if you feel the need to chase this down.
Hopefully that answers some of the questions.
– Alden
MemberDo I take it that you are running Coolterm on Windows XP? The details of your configuration might be enlightening. Are you native, in a VM? What version CoolTerm? Let’s check to make sure you have XON enabled in the firmware – can you send your $$ config?
You can verify XON/XOFF operation by looking at the XON/XOFF LED to see what’s happening. You can tell when XON/XOFF is working by looking at the GPIO port LED that is closest to the USB port. Note: this is not the RX/TX LEDS that are right next to the USB connector itself. It turns on when XOFF is issued (communications halted) and off again when communication resumes.
We have found that the XON/XOFF implementation within TinyG works reliably – at least it’s entirely consistent and predictable at the board level. How well it works as an end-to-end system – however – depends on how the host terminal program handles it, which is usually by passing the control down to the drivers on the host. We believe that the FTDI drivers work well, but we haven’t tested every single combination! How the host program handles XON/XOFF can also vary. I have no problems running Coolterm from Mac OSX, and Riley runs it from his Windows machine. But beyond that we don’t have a good handle on how other host/driver combinations work.
Given this variability, tgFX synchronizes on the responses. It uses the JSON interface, so you will need to complete your upgrade to 0.93. The current release candidate for 0.93 is build 338.05 which can be found in the edge branch.
So the XON/XOFF issues should be a stopgap – once we get tgFX out and running we will be past the machine variability in XON/XOFF.
MemberI just ran the boxes_gcode_circle file and it completed fine. I was running Coolterm on Mac, with Xon/Xoff enabled. I got the entire box, circle and 114 degree. Just for yuks, can you try inserting a brief delay between lines in Coolterm? Say about 1 ms?
Alden
MemberGood question. I refer you to the following discussion on the grbl github about emergency stop:
https://github.com/grbl/grbl/issues/51 -
AuthorPosts
