alden

Forum Replies Created

Viewing 15 posts - 16 through 30 (of 702 total)
  • Author
    Posts
  • in reply to: 440.16 Firmware still having arc issues #8161
    alden
    Member

    No problem. Any time is fine. I can definitely use them.

    You should be able to get the new file from the updater. I’d recommend using Master-440.18. Edge is (as always) a work in process.

    Thanks for the help.

    in reply to: 440.16 Firmware still having arc issues #8151
    alden
    Member

    I did run the E file. Ran fine to the end. Is it possible to get these files with a single pass – no depth-of-cut (i.e. multiple passes)? That way I can use them for regression testing with a pen plotter. I will get the revised code pushed to edge over the weekend so you can test using the updater.

    in reply to: 440.16 Firmware still having arc issues #8148
    alden
    Member

    I’ve been after this bug for a while, so your misfortune is my opportunity. Thanks for the excellent files. I got about 75% of the way through sullycut before we had a power glitch (house power, not my machining setup). But it ran well up to then and the errors in that one were way back at the beginning. I ran the iolated Avery V withou error, and am running the full Avery10x10 now but the error there is much later in the file. I’m using OpenSCAM as a previewer. Great program. I’ll report back as I get more information.

    • This reply was modified 9 years, 3 months ago by alden.
    in reply to: 440.16 Firmware still having arc issues #8146
    alden
    Member

    Thanks. I have sullycut working well. Still going through the entire file just to be sure. Takes a while, as I’m sure you are aware.

    in reply to: 440.16 Firmware still having arc issues #8143
    alden
    Member

    Making progress here. Is it possible you could generate a complete Avery file that is only 10 inches in diameter? I am testing on a machine that cannot accommodate the 24″ extent of the entire file. If this is not practical I can make do with the existing files. Thanks.

    in reply to: 440.16 Firmware still having arc issues #8142
    alden
    Member

    OK. I need to dig in here to see what’s going on. I’ll report back. Sorry for the issues and thanks for your patience.

    in reply to: 440.16 Firmware still having arc issues #8138
    alden
    Member

    I’ve had a chance to test averyV in 440.17 and in edge-441-arc. It fails as you said in 440.17 and looks to be OK in the edge-441.arc branch. If you have a chance can you run the jobs to verify?

    441 should be available here:
    http://synthetos.github.io/

    Which means it should work with the updater.

    in reply to: 440.16 Firmware still having arc issues #8132
    alden
    Member

    Thanks for posting. I am away from my setup today but will get to these later this week.

    in reply to: TinyG shorted out during gcode test #8131
    alden
    Member

    Sorry for the problem. We will replace the board. Can you please send the failed board back for diagnosis? We will pay shipping. Please contact customer support.

    in reply to: 440.16 Firmware still having arc issues #8120
    alden
    Member

    Yes, please do post the other file. This will help test.

    in reply to: 440.16 Firmware still having arc issues #8113
    alden
    Member

    I did some experimentation this evening and think I have located the source of the wandering arc. Line 163 in sullycut (my numbering, not Chilipeppr’s – which are close but not exactly the same) has a huge I offset that I don’t think was being handled correctly.

    N163 G2 X1.0224 Y3.869 I1244889.1849 J0.537

    If you are so inclined you can use following hex, or compile from the github branch edge-441-arc.
    https://www.dropbox.com/s/wgqqpz50q3twapb/tinyg_441.01_edge.hex?dl=0

    Please be advised that this has not been fully tested yet for any side effects or regressions. But if you would like to test I would appreciate any feedback. As I said in my earlier post – I will be traveling this week but should get back to this late in the week and over the weekend.

    in reply to: 440.16 Firmware still having arc issues #8109
    alden
    Member

    Thanks for the heads up. I have a number of changes/fixes I made to arcs in the g2 branch that have not made it back into the main branch yet. I will pick this up ASAP. I will be traveling for the next few days, so I expect to get to this late in the week / weekend.

    in reply to: Mapping A-axis as linear #7772
    alden
    Member

    Glad you worked that out. The other way to do this is to set the rotary axis (A, B, or C) in Radius mode, then set a radius value for the axis. This interprets linear input as if it were wrapped around a disk. This is explained on the wiki on the configuration page under Radius mode. You have to work the math a bit, but it does work.

    in reply to: Communication issue with TinyG #7771
    alden
    Member

    Judging from your output it looks like not all the characters are getting to the serial reader, or are being clobbered in the serial buffer due to some kind of problem. For example this exchange:

    Sent: G10 L2 P1 X3.6 Y0 Z0
    Sent: {rx:n}
    Received: {“r”:{},”f”:[1,0,21,101]}
    Sent: {rx:n}
    Sent: {rx:n}
    Received: {“r”:{“err”:”{r”},”f”:[1,108,3,7863]}

    If I read this correctly, what’s happening is that the sender sent the G10, then sent an rx:n immediately (before waiting for a response from the G10), then received the response from the G10, then sent another rx:n, then another, and finally received the response from the first rx:n which was mangled.

    The error response indicates that of the first ‘{rx:n}\n’ only the ‘{r\n’ was received by the board (with the \n being the newline character). This is evidenced by the footer reporting that the line read 3 bytes – the ‘3’ is the number of bytes read by this command in the 3rd footer position, and the error response saying that it only say ‘{r’ and could not process it. Returning status code 108.

    It’s a good idea to wait for a response from one command before sending the next. It may also be helpful to you to increase the JSON verbosity to max: {jv:5}. That way you can see what command was issued in the {r response – at least during debugging.

    My take is that the system is in an unresponsive state after the G10, as it has to write to EEPROM. Waiting for the response will allow the write to complete. You might also try delaying your next send by at least 50 milliseconds, but waiting for a response is a better way to synchronize.

    This is due to a flaw in the Xmega EEPROM write functions that force turning interrupts off while EEPROM is being written. So the serial interrupts may be off explaining the dropped characters from the rx:n request. This update window affects any command that writes to EEPROM, which is all configuration commands that write values (e.g. {xvm:1200}) and the G10 in Gcode, which is the only Gcode command that actually writes to persistent memory.

    (Technically, these writes are deferred while the board is in a machining cycle, but since it was not in a machining cycle in your example the write occurred immediately after the G10 parameters were received).

    Alden

    in reply to: It is possible to interrupt homing cycle? #7770
    alden
    Member

    There is no way to “quit out” of the homing cycle once it’s started. However, sending a control X (^x) should reset the system. Is this what you need?

Viewing 15 posts - 16 through 30 (of 702 total)