Riley

Forum Replies Created

Viewing 15 posts - 121 through 135 (of 260 total)
  • Author
    Posts
  • in reply to: Grbl Controller 3.4.1 /dev/ttyS0 #4401
    Riley
    Keymaster

    Candungo,

    I would check back with posting a comment on that blog for help. These forums are for the grblShield support. If you can use a terminal like cool term and make the grblShield move your motors then that will verify your gShield is working.

    I have never got grbl working with my RPi.

    Riley

    in reply to: TinyG skipping gcode lines #4341
    Riley
    Keymaster

    Sweet! yah noise can be a bit tricky. It is super hard to track when you have different hardware than us as well.

    in reply to: Selectable Defaults #4340
    Riley
    Keymaster

    Rob and I are both working on a NodeJS setup for a web UI. So instead of us all working on the same plumbing, we should focus on all working together on a setup here? Thoughts?

    in reply to: TinyG skipping gcode lines #4310
    Riley
    Keymaster

    I am running this 370.01

    At this link:

    https://raw.github.com/synthetos/TinyG/e160f2832403387d47a4ff1c08e34ea237fda709/firmware/tinyg/default/tinyg.hex

    (right click save as)

    I removed the ;’s and I ran your file np. You could give this a shot. As far as M8 and M9 with delays. There are other (myself included) running these commands 🙂

    In your config you have your X and Y max velocity’s set to 250 Inch per min.
    Thats 6350.0mm /min …. Thats very fast for a lead screw machine. What file are you trying to send when the velocity goes crazy? Is it the same one you linked above?

    We are trying to help you. However testing and tracking down issues does not happen overnight. I realize it can be frustrating. Just please note we are working on the issue.

    Riley

    in reply to: TinyG skipping gcode lines #4308
    Riley
    Keymaster

    Well I ran your file and there is some very odd behavior indeed! However, I removed all of the ;’s and this is what I got.

    tgFX Running

    Looks like the is a bug in the way “;” are being handled either by tgFX or TinyG. We have to look at this one harder. However, I would suggest you NOT use files with ;’s in them for now 🙂

    Riley

    in reply to: TinyG skipping gcode lines #4302
    Riley
    Keymaster

    Oh ok I did not read your first post. 2 things. One is your firmware has a bug in it. We have identified that (the ,,,,,,,,,,,,,,,,,,,,,,qr’s on reset) so you should get a new version. I would recommend the hex file that is in master branch right now. We have a newer version in edge but I want to test it a bit more. So first up flash to master. Second, just for fun. Try killing all of those “;” and re-running this in tgFX. I am not sure if this is an issue but its worth testing out.

    Lets see what that does.

    Riley

    in reply to: TinyG skipping gcode lines #4301
    Riley
    Keymaster

    tgFX turns XON off too, as we use byte counting in the serial buffer to address this. Also, I would try turning off your cylinder and running the job in tgFX. I would like to verify that it is not noise.

    Riley

    in reply to: How to view messages during operation #4300
    Riley
    Keymaster

    Interesting. Matt and I use a different flow control mechanism than XON. I would say that running tgFX or matt’s code causes this to trigger as “coincident” however if you continue to see it work in coolterm perhaps not. Does this happen on all gcode files? Or specific ones? If its on specific ones I will need to gcode files to replicate this.

    tgFX will turn $ex=0 on connect btw.

    I looked up why the limit switch message would be presented. Its due to an “er” message from TinyG. This perhaps is not the best single identifier for this case.

    In ResponseParser.java insert this line to line #435
    <br>
    Main.postConsoleMessage(“ERROR: ” + message);
    <br>
    And try your whole setup again. This should post a message to the console telling you the whole json message that TinyG sent. It should start with “er”.

    I would like to know the rest of it.

    in reply to: How to talk to TinyG from Linux?? #4292
    Riley
    Keymaster

    The current linux build has an issue. Its looking for the JRE in the wrong place. I am working on getting an installer that works on ubuntu. However its not right yet.

    You can however, clone the repo and run it on linux from netbeans. Not ideal but good until I get a binary that WORKS.

    Riley

    in reply to: TinyG skipping gcode lines #4291
    Riley
    Keymaster

    Sorry to hear are having issues. I would need to see your gcode files. Also, you should read the Readme.md if you have not had a chance.

    https://github.com/synthetos/tgFX/blob/master/README.md

    It pretty much spells out that tgFX is under development. If you are doing any jobs that are $$$ you are better off not using tgFX to avoid the mistakes you bring up.

    Coolterm + XON send file works 100% of the time right now. However you do not get the stop pause resume stuff.

    Attach your gcode I will take a look. Also, can you give me your build number? Are you running a binary that I packaged or is this straight from netbeans? Also, reset your board while connected to coolterm and paste in what comes back.

    Riley

    in reply to: How to view messages during operation #4288
    Riley
    Keymaster

    I had lots of noise problems with my Panther PCB mill. Specifically the spindle. I solved it by getting an UPS and moving the power for the spindle to that and the computer to a different circuit. I would also make sure you have your homing switches set to disabled (if you are not using them) and if you are using them make sure you are using normally closed switches.

    That being said getting message from tgFX on err I can do. I will open and issue with this and get it coded up.

    If you think you are having noise issues I would see what it says via coolterm + xon for now for sending files.

    If your board starts blinking (red light flashing like reset) mid job then this sounds like it could be noise related.

    I had the option for a log on the gcode buffer but the way it was coded was to log to memory then write it out later. Needless to say it was a huge memory leak so I pulled it. I can open an debug mode as well that will write out a debug file of all tinyg responses process.

    Riley

    in reply to: Another firmware flash required #4277
    Riley
    Keymaster

    Cool thanks for the video. Ok so it looks like you still have the ability to on “power on” enter the “bootloader update mode” which is when the red led is flashing a pon power up. Have you tried getting your avrdude command to update your firmware all queued up (read just ready to hit enter button) power on the board then hit enter while the lights are flashing?

    Here are the instructions for doing so:
    https://github.com/synthetos/TinyG/wiki/TinyG-Boot-Loader#wiki-updating

    Just to be clear all you need to do this is your USB cabled hooked up to your tinyg like normal. Then using avrdude you should be able to re-flash the tinyg firmware (not bootloader).

    See what happens when you try that.

    in reply to: Another firmware flash required #4267
    Riley
    Keymaster

    LTMNO,

    This is what I get for replying to posts at 1am. That reply was meant for a completely different topic!

    What firmware version do you have? Can you paste what comes back at startup? Also, you will need an AVRISP MKII to re-program your tinyg. Does your board start blinking when you power it on? If it does that means you are in bootloader mode.

    If you can get into bootloader mode I suggest you try flashing the tinyg.hex and see if this clears your issues up.

    in reply to: problem flashing my TinyG #4265
    Riley
    Keymaster

    Well.. I am not sure. See your board had the bootloader loaded on it. All you needed to do was flash via avrdude the tinyg.hex file. I am not sure what “state” your board is in now since you reflashed the bootloader. Unless you changed any “fuses” you should be ok if your reloaded the bootloader.

    That being said… save that file like told you how.. then hit “reset” (led should be flashing) then hit enter with the whole command line that was give via the instructions.

    If you are still having issues shoot me an email at riley &nospace& porter @ gmail.com and I can setup a google hangout or cell phone call to help you out. I we are hackers too I totally get trying to mess with stuff

    Riley

    PS
    To put your mind to rest. Nothing you did should have “bricked” your tinyg. And being that you have an MKII you are gold. This is a speed bump in your road to CNC awesomeness.

    in reply to: Another firmware flash required #4261
    Riley
    Keymaster

    This sounds like you do not have a valid download of the tinyg.hex file. Try this.

    TinyG Hex

    Right click save as on that link. Then try flashing that.

Viewing 15 posts - 121 through 135 (of 260 total)