cmcgrath5035

You will likely find this list easier to decipher:
Function Due Pin
pin_number kXAxis_MinPinNumber = 14;
pin_number kXAxis_MaxPinNumber = 15;
pin_number kYAxis_MinPinNumber = 16;
pin_number kYAxis_MaxPinNumber = 17;
pin_number kZAxis_MinPinNumber = 18;
pin_number kZAxis_MaxPinNumber = 19;

pin_number kAAxis_MinPinNumber = 58;
pin_number kAAxis_MaxPinNumber = 59;
pin_number kBAxis_MinPinNumber = 60;
pin_number kBAxis_MaxPinNumber = 61;
pin_number kCAxis_MinPinNumber = 65;
pin_number kCAxis_MaxPinNumber = 51;

They appear to be raw connection to pins on the uC. If there is a pullup, it is on chip not on board.

Derived from:

https://github.com/synthetos/g2/blob/edge/TinyG2/platform/atmel_sam/board/due/gShield-pinout.h

Here are a couple of suggestions. Based on your description, your issues are between MACOS and tinyG for now and you have CoolTerm installed. You need to resolve the usb port connectivity issue before moving on to CP.

I cannot help directly with MACOS specifics, I run on Linux, so will speak Linux and expect you to translate to MACOS dialect. I know MACOS has its roots in Unix so is similar, but unique in detailed ways I am not familiar with.

Step one is to get MACOS properly accepting a connection from tinyG.
Here is what I would do in Linux space:
1. disconnect tinyG’s USB from MAC
2. Reboot MAC
3. With a GUI file manager, navigate to /dev and click the GUI to sort the display of devices under /dev by date, decending order, most recent on top.
4. The most recent, and probably everything, will have a date field that is same as the boot time.
5. Without connecting tinyG yet, power it up and wait for the flashing LED to stop flashing (boot is complete). Hit the reset button, it will reboot(this is probably redundant, but ensures a clean boot, free of power up induced glitches, should they exist).
6. TinyG still not connected, refresh your file manager GUI.
7. Now insert tinyG’s USB into the MAC, then refresh you GUI again (or it may auto-refresh).
8. You should see a new device appear under /dev, with connect time the insertion of the tinyG USB cable.
9. If there is no change in the /dev/ device list, you likely have an ftdi driver install issue. Devices appear as /dev/ttyUSB0 (Linux speak, not MAC) only after USB insertion detection and proper driver startup.
10. Open a command line console window in you GUI. In Linux, a ‘dmesg’ command will dump a long stream of messages, the most recent of which should be related to the USB insertion. In this file (URL) you will see the results of the dmesg command on my Linux machine, The top three lines are a disconnect event, the balance are the messages issued by the USB services after re-insertion, loading and starting up the driver.

https://dl.dropboxusercontent.com/u/50261731/dmesgtinyG.txt

11. If you do not see a new device appear in /dev, still check the output of ‘dmesg’ command. If the new USB device insertion was seen by MACOS, you will then likely see some error messages related to install driver failure for the new USB device. If there is nothing in the ‘dmesg’ report, perhaps try a different USB cable? It would not be the first time the cable turned defective in one of these adventures.
12. If MACos does not support ‘dmesg’ from the command line, look with an editor at the bottom of the system messages file. In Linux, from CLI, that would be ‘cat /var/log/messages | tail’, outputting USB related messages similar to dmesg above (tail by default prints only bottom 20 lines)

See if any of this produces useful information.
Hopefully someone who is more familiar with you version of MACos will stop by and more precisely speak your language.

AND, when you are finally getting a usable tinyG USB connection, get CoolTerm working again as it is somewhat simpler than Chhilipeppr.
Then move on to Chilipeppr again. What version of the serial-port-json-server do you have installed? Version 1.77 is the latest.

FINALLY, know that I will then recommend you update your tinyG FW to build 438.02. Build 380.08 is rather dated, will get you going with CoolTerm and probably Chilipeppr, but Chillipeppr works best with enhanced tinyG status messaging that is in 438.02 FW (and beyond).

First, be mindful that the Due (and tinyGv9s) are 3.3V logic. so any external ‘weak’ pull-up must be to 3.3v, not 5V as in Uno space.

Second, Run CP from this

URL: http://chilipeppr.com/tinyg?v9=true

.
depending on your FW build ($fb) of tinyG2, this variant is necessary due to some issues observed in G2 with the CP start-up sequence.Necessary for build 71.04(by experiment), no experience with later builds(or earlier builds for that matter)

Third, – In searching about, I realize that a Wiki Item like “Connecting to Due running tinyG2” isn’t there yet.

Info I can dig up say your might find the following function on the following pins:
DUE port Pin
PA10 3 RXD0 D19 Zmax
PA11 4 TXD0 D18 Zmin
PA12 5 RXD1 iL D17 Ymax
PA13 6 TXD1 2H D16 Ymin
PD4 17 TXD3 D14 Xmin
PD5 18 RXD3 D15 Xmax

I highly recommend a test before committing, I have a somewhat older pin/port assignment and this may not be correct.

You can check with a voltmeter, but I would not expect there not to be pull-ups on a Due, so you may need to provide – to 3.3V!

• This reply was modified 9 years, 12 months ago by cmcgrath5035.
• This reply was modified 9 years, 12 months ago by cmcgrath5035.

cmcta82 – Probably, once the tinyG fw accommodates this. Still being worked at Synthetos

By the way, when running Chilipeppr with G2 build 71.02, you should use the URL

http://chilipeppr.com/tinyg?v9=true

You can also select this from the TinyG widget drop down menu in CP, which will reload CP at that URL.

When CP connects to tinyG, it sends a string of commands and queries to bring tinyG to a known state. Some elements of the tinyG startup cause issues with G2 build 71.02. Those problematic commands are bypassed when URL?v9=true starts up. CP seems to work, although the root cause of this startup issue is still being investigated.

Also, I would recommend you keep an eye on traffic at

https://github.com/synthetos/g2/issues

github/Issues is sort of the bug tracking mechanism, but lots of other tid bits pop up.

• This reply was modified 10 years ago by cmcgrath5035.

These are observations, not answers.

Are you building a 3D printer from scratch, or purchasing a kit?
If a kit, it will likely come with some sort of controller, you could use the experience of learning that to decide how much more customization and personalization you want. You might choose then to retrofit the mechanicals with tinyG2 based control.
TinyG and tinyG2 provide Motor and Axis controls for machines, robots, whatever you want as long as you can control them with GCode. tinyG provides 4 motor/axis controls from 6 GCode defined axies: X,Y,Z,A,B,C.
tinyG2 will have the compute resources to implement all 6 simultaneously.
Does you vision of a 3Dprinter require more than 4?

While G2 documentation might seem “thin”, consider that a significant amount of the tinyG documentation applies in theory if not in precise detail. The G2 wiki is rather verbose on the important aspects of G2, which are how you could implement additions and modifications to software based-on-tinyG2.
A full 3DPrinter implementation will be a lot more than just tinyG or tinyG2 firmware. That said, there are numerous implementations of 3D printers implemented on machine cores running tinyG right now, they are easily foun online.

I might suggest you sit back and watch this on-line video:

https://www.youtube.com/watch?v=xdSwOl7YrRg

While he video is Chilipeppr centric, think of CP here as a development environment for what needs to be implemented on top of tinyG or tinyG2. Tigershark is a project based in tinyG2 firmware compatible custom hardware. In the video look for the tigershark developers thinking on what the layer of functionality surrounding tinyG2 software needs to be. Along the way, numerous state-of-the-art tools and concepts are discussed.

From there decide if you want to go it alone or lurk around a work in progress, building along with another project and making/contributing your own ideas and implementations.

Good Luck! You will learn a whole lot, whatever you decide to do.

Well yes, but the only parameter being set is $ztr, travel per one revolution.
If the pitch is 10 Threads per Inch, a nut, or the Z axis Lead Screw Nut, will move 1/10″ per revolution, or 2.54mm =$ztr

tinyG does all the distance per step and distance per microstep calcs for you, based on the $_sa = 1.8 degrees ( which is 360 degrees/200 steps) and the $_mi microsteps per step parameter.
If you want tinyG to use smaller steps, eg $_mi=8, you just set that parameter and tinyG computes a new distance per microstep,
$_mi=4 is recommended because 1/314.960mm is already really fine precision for typical milling.

Driving a laser engraver or a 3D printer may introduce additional considerations.

Thanks for the report back.
On and off folks have similar questions as yours.
Was there something obvious, such as coil winding resistance, that was a definitve indicator?
Seems on some machines the motors become an integral part of the assembly and difficult to disengage from the drive mechanism.

Happy CNCing!