Forum Replies Created
-
AuthorPosts
-
greyhound716
MemberSince the basic jog code is working fairly well, I’m putting some work into the USB code. Lot of loose ends, but before I polish anything up I want to get all of the parts working. I’ll try to get another video up this weekend.
-MattMemberFabrice,
I have a Viewsonic tablet running ICS, and it sees the FTDI natively. On my github site (https://github.com/mattstock), you’ll find a few applications I think you will find useful. In particular, the USB-Device-Info app that I forked will be able to tell you if your tablet sees the USB device at all. If yours is similar to mine, it should show up.
I’m looking to do the same thing you are. If you look at one of my other github projects android-tinyg-usb, that’s going to be my solution for what you describe. I’m using the USB host mode API to obtain the I/O streams, and from that point on the interactions will be similar to my existing jogger application.
If you want to play around but you aren’t ready to use tgFX, I also have a NetToSerial java program you can run on your PC connected to TinyG. Use the android-tinyg app to connect to the PC via your wireless network. I need to put together some documentation on this soon.
The Android architecture I’m planning to use will involve a “core” application (android-tinyg) that has the main UI and the network-to-tgFX code, and a helper application that have an Android service and a few setup activities that will connect directly via local USB in host mode. If you want to use USB, you’ll need to install the 2nd app, but it shouldn’t require much else.
If you have any thoughts about the design or want to help with testing, let me know.
-MattMemberThanks. It’s starting to come together. I’ve added some new display capabilities, allowing you to interrogate (and soon change) the TinyG settings (motors, axis, system). In the process, I’ve run into a problem with tgFX. It seems to only be sending me every other JSON response from TinyG. I can confirm the lines aren’t being sent from tgFX, and if I use the same app pointing to a simple serial to network java app, I get all of the data. I assume it’s related in some way to the OK handshaking, but I haven’t looked into it too much.
Most of the base functionality on a small scale (phone sized) unit is there. I still have to do some work on file uploads and I’d like to see if I can get the fragments to work properly on a tablet-sized unit. I hope to have a real demo out in the next week or so.
-MattMemberThere are a couple of options I can think of, even if that’s not a short-term feature..
If you’re willing to do a little soldering, I think you could adapt the switch input using a transistor. It’s been a while, but since we’re only talking 3.3v, you should be able to bias the transistor to pass current (NC) until your switch is pressed, which shorts the base to ground.
If you’re more of a software person, you can probably hack the TinyG code to either use one of the GPIOs for your limit switch or program one for NO functioning. I haven’t looked at that part of the code, but inverting the input from one of the limit bits shouldn’t be that difficult.
-MattMemberGreat, I wasn’t aware of the JSON format commands and queries – I thought it was only for the automatic status data. I’m going to modify what I’ve already done to use JSON instead. Assuming most of this is .93, I’ll wait to see what’s there.
In the meantime, I’m looking at javaFX for Chumby. Unfortunately, it is ARM v5 based. There’s a plain vanilla JVM available, but it’s unclear to me right now if I can get the javaFX bits to work.
MemberVery nice. I have a JSON parser for the status stuff, but I found it awkward to parse the output of ? to get the initialization state. Looking forward to testing out .93.
MemberSounds cool. I’ve got a basic sketch of my UI for the Chumby written in perl, but it looks like we’re driving toward something similar. If I can get your stuff to run on the Chumby, I’d be happy to help with development.
-MattMemberHave you tried typing commands to the TinyG board by hand? I have not used CoolTerm, but assuming that you have selected the correct COM port, have the unit powered on, plugged in, etc, when you press the reset support on the TinyG you should get a greeting message and a prompt in your terminal window. If you type, it should echo, and you can manually type gcode to the board.
If that isn’t working and you have the serial speed set correctly, you’re either not connected to the right serial port, or there’s some other low-level issue. I’d start by figuring out if Windows recognizes the board when you plug it in by looking at your devices list. In Windows 7, mine shows up as a “FT232R USB UART”.
MemberNope, you have it in one. I also have an Arduino Uno and was considering going down the exact chain you are, but decided that I’d be better off if I used a box that already had all the features (and then some) I was looking for.
I’m starting to put together a development setup now. Since my primary interest is getting something put together that’s durable and quick and it’s been a few years since I was a hardcore programmer, I still haven’t decided what to code this in. I think it’s mostly going to be driven by how I want to interact with the Chumby screen, and so more experimentation is needed.
It’s all talk until you share the code, right? 🙂
MemberLooking at your video, make sure you have the correct serial port speeds – I believe it should be 115200, not 9600. If you hit enter a few times, you should see the tinyg prompt. also, make sure you use software (XON/XOFF) flow control, not hardware. Try running a few gcode commands manually and make sure your steppers jog, set your current limits and seek rates, etc.
Good luck!
Memberjmnoeth,
Beagle looks nice. I’m doing something similar, but going to use an existing Chumby.
I actually was fairly successful “plotting” a picture as my second test run. Took a picture of my daughter, ramped up the contrast, and fed it to Inkscape to do edge detection, path generation, and G code export. There were a lot of “noise” paths however, and I’d need to clean that up before doing it for real. It was a good test of the board though – heat dissipation is good, though one of the copper radiators got up to 180F, the chip didn’t go into thermal shutdown.
Let me know how your interface works. I’m playing around with using a Chumby One right now for the same purpose. I also need to get a routing toolhead constructed!
-MattMemberThanks for the tip! I’ll take a look at getting a bigger supply.
MemberSounds like a plan!
MemberOk, good news and bad news. I flashed the firmware, but I’m still getting similar behaviors with the driver. I definitely have the newer firmware on the board (it reports 326.06 now). When I run the test series you describe above, with the axis mapped normally and not, there is no change to the position information and the motors don’t fire.
I did a couple more experiments… It looks like only X is working, and only for g1. If I set a feed rate of 400, switch to g1 mode, and move X, it fires the motor and changes the internal position. If I $1ma0, $2ma0, $3ma0, $4ma0, ALL of the motors fire. In the last case, it looks like it is pulsing output 4, but the others are continuous. I’m currently testing without motors attached, just looking at the LED outputs.
I’m happy to test anything you can think of that might shed light on what’s going on.
Should I try to erase the EEPROM? It seems like it preserved the settings from when I re-flashed, but if I can get it back to a factory default that would be good.
-MattMemberThanks for the info. I don’t have a programmer yet, but I was planning to get one soon. I actually bought the one from SparkFun before I realized it doesn’t support Xmega. :-/
I noticed the rev, but figured it was a minor and probably didn’t matter!
I’ll let you know when I reprogram and if there are any issues.
-Matt -
AuthorPosts
