Forum Replies Created
-
AuthorPosts
-
burnsb
MemberFwiw, I bypassed the usb on both the Rpi and the Tinyg, and instead used the Rpi and Tinyg uart. As they are both 3v logic I just connected up the two lines and ground. I did this because I didn’t want to add a usb hub to be able to use X.
It wouldn’t surprise me if the broadcom hardware uart was superior to the Raspbian software serial routines.
Memberlalee- very cool.
liseman- I’m not famillar with OctoPrint, but what distro are you using and what are your port settings?
I haven’t had much time to work on this lately (been doing piecework with my lathe on the weekends for extra money).
Last thing I did was getting a tinyg state loaded into python, i.e. all co-ords, active codes, etc. Having trouble with some sort of overflow. I’m at work and can’t remember exactly what the issue was, but it seemed to be an error on the pi side. I may try slowing down the baud as lalee suggests.
MemberSorry for the late post. Still working on this project. Currently have the Rpi talking json to the tg. Working on gui stuff with tkinter.
As far as minicom goes, I’ve quit using it. Instead I’ve been using miniterm:
pi@raspberrypi /usr/bin $ miniterm.py -e –cr /dev/ttyAMA0 115200-
This reply was modified 11 years, 4 months ago by
burnsb. Reason: formatting
MemberVery cool, I’m going to try and start a blog this weekend on my cnc build. I guess you saw my thread in the project forum. As well as the blog I hope to get python on the Raspberry Pi interpretting the Tinyg JSON output.
I’ve been thinking about the canned cycle stuff also. We could take your script and modify it to break canned calls to straight g-code inline to the Tinyg. Note that the Tinyg has a pretty good line numbering scheme and this would be very useful for something like this. Strip any Nxxxx from the program on the Rpi and substitute another Nxxxx that is being sent to the Tinyg to keep proper track of the program. The same methods to use canned cycles would also be applicable to calling sub programs(M98, M99) and some type of macro system.
Have you done any gui stuff with python? Maybe we could set up a git for this and start working on it together, if you would be interested. As you can see, I’m interested in using the Rpi for the frontend as it is cheap, has good support for the gpio and low level hardware, and would be a standardized platform. I’ve been looking at using Python 2. But if you want 3, we can do that.
I’m a machinist by trade and at one time was profficent with Surfcam and Mastercam, been a few years since I was a fulltime cnc programmer but feel free to ask me any general cam or machining questions. I’ve played with microcontrollers in JAL, C, and assembly as a hobby for 5 years or so.
MemberGot python on the Rpi talking to the TinyG.
I should add that I’m using the Adafruit version of Raspbian, Occidentalis which has enhanced low-level hardware support.
After freeing up the uart as in my above post, install the python-serial routines. (Same process to install minicom, you must have network connection to install either of these. Although there are ways of doing it with manually downloaded packages)
At a command prompt enter:
<code>sudo apt-get install python-serial</code>
Before I was able to get python-serial to work I had to reboot the Rpi. I suspect that the port was not free due to prior minicom use.
In IDLE I created a new file. Note, don’t name it serial. It will try to import the current file if you do.
test code:
<code>
import serial
serialport = serial.Serial(“/dev/ttyAMA0”, 115200, timeout=0.5)
serialport.write(“\r”)
serialport.write(“?\r”)
response = serialport.readlines(None)
print str(response)
</code>When the port is opened by python, it sends the TinyG an x character. I haven’t figured out where this is coming from.
Next up is learning about JSON, how to use python’s JSON interpreter, and learning enough python to do what I want.I hope in the next few weeks to begin a blog with an overview of my garage/shop and journal the build process. Particularly relevant developments to the TinyG I will repost here if that is okay.
End goals:
I plan to build a CNC mill/printer. It will have removable heads such that either a milling spindle or 3d printer head may be used. When in milling configuration it will have available table mounted 4th axis for rotary milling capability. The bed will be mounted to the X axis, Y and Z axis on a bridge. Raspberry Pi based gui frontend for the TinyG incorporating the various features of CNC controls I like. I want to take from the feature sets of Fanuc, HAAS, Fadal, and even a couple of things from the Acramatic series. I want to build a pendant that in addition to a handwheel, controls most machine functions. Somewhat like the later Cincinnati or HAAS pendants. It will interface through spi to the Rpi.To these ends I have a Atlas 6″ lathe with milling attachment, and an asian floormount drill press, and various other power and hand tools. 4 3.4V 2.0A NEMA23 steppers in the 100 oz/in range.
September 5, 2012 at 9:13 pm in reply to: G83 canned cycle, applicable to other canned cycles. #3463MemberFirst, machine (absolute) coordinates are implemented (G53), as are 6 work coordinate systems, G54, G55, G56, G57, G58 and G59. G92 offsets are also implemented as proper G92, G92.1, G92.2 and G92.3 as per Kramer (NIST RS274NGC-V3) If you remember where you read that machine coordinates are not available I’d appreciate a pointer. Sounds like the wiki has inconsistent data and I’d like to fix that. Otherwise I’ll just hunt for it. Time for a revision pass anyway.
Instead of the all this TinyG implements the following:
On power up the Gcode interpreter is set to zero (X,Y,Z), which makes the machine zero the current (possibly random) position of the tool. A single coordinate system is provided. G10, G43, and G54 – G59 are not implemented.
A reduced functionality G92 / G92.1 is available that does the following: G92 accepts axis-value pairs for all axes. The value will set that axis to the value. One or more axes must be provided. Axes that are not provided are not changed. For example, to zero a robot you can enter the below. Or just G92.1 which is a G92 with all axes being equal to zero.This led me to think that G54 etc. wasn’t implemented. Even though it appeared in my example g-code out of habit. I was understanding the control to be implementing the G92 style of offsetting like Acramatic controls. (Possibly my least favorite control ever, at least the versions from the ’80s and ’90s ) 🙂
— Unsupported Commands:
G10 Coordinate system data
G14, G15 Spiral motion
G28, G30 Return to home (requires parameters)
G38.2 Straight probe
G40, G41, G42 Cutter radius compensation
G43, G49 Tool length offsets
G54 – G59.3 Select coordinate system (group 12)
G61, G61.1, G64 Set path control mode (group 13)
G81 – G89 Canned cycles
G92 – G92.3 Coordinate system offsets
G98, G99 Set canned cycle return levelM6 Tool change
M7, M8, M9 Coolant (group8)
M48, M49 Enable/disable feed and speed override switches (group 9)September 2, 2012 at 2:17 am in reply to: G83 canned cycle, applicable to other canned cycles. #3454MemberThank you for the response. It seems I have homework. 🙂
I’ve seen Github. I’ll continue this there if I manage to come up with anything more to contribute. I’ll run down the statement about machine co-ords not being implemented and let you know. I think I’ve got my wife convinced I need this controller and hope to be playing with it soon. 🙂
-
This reply was modified 11 years, 4 months ago by
-
AuthorPosts
