flux

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 31 total)
1 2 3
  • Author
    Posts
  • November 10, 2014 at 3:12 pm in reply to: Broke my TinyGv8 #6980
    flux
    Member

    So, I finally did the effort of replacing the FTDI chip.

    And, lo behold, it works! Well, at least it interacts with the replacement USB hub and the computer, I didn’t hook it up to the motors yet. The quality of my soldering.. Well only time will tell :).

    An additional bonus I got from the new FTDI chips, was new speeds: I didn’t recall being able to go to 460800 and 921600 bps before switching the chip, probably a new revision of it even if it is the same type. It’s probably easy to add support to those speeds to TinyG, but I wonder, is it worth it? Will TinyG be able to process that speed? At least it would be faster to send responses to the host machine.

    In any case, I’m happy that I’ll be able to check out what is cooking with the software, resume doing PCBs and try breaking the board again :).

    September 10, 2014 at 3:28 pm in reply to: Broke my TinyGv8 #6752
    flux
    Member

    It’s v8.

    Yeah, perhaps I should have done some measurements first (and still could do..) on the voltage levels around the FTDI chip just to be sure FTDI has power, though how would I know if it’s not pulling a line down when broken without removing it, which I of course need to do at some point.

    In the v8 there is also this two-line EDS protection diode PESDxL2BT which could be broken, but surely it wouldn’t break in a way that makes it short the GND with USB signal lines? And if it’s defunct now, it ‘only’ removes the ESD protection.. But now I will have plenty of spare FTDIs, no sense ordering only one at those shipping costs ;).

    I should also hook up the TTL serial up to see if I can communicate over that. Probably not the final solution even if it works.

    Thanks for pointing that out even if it didn’t match ;).

    September 10, 2014 at 2:03 pm in reply to: Broke my TinyGv8 #6750
    flux
    Member

    Well, I ordered a few FT230XS chips from Mouser, so I shall see if it works after replacement after a week or so.

    September 10, 2014 at 12:37 am in reply to: Broke my TinyGv8 #6745
    flux
    Member

    Practical reasons. I have quite a few USB devices and the USB port of the PC is difficult to reach, so I’ve brought the USB ports reachable with a few USB hubs.

    Yes, I too am happy for having the hub there ;).

    September 9, 2014 at 2:13 am in reply to: Networking two TinyGs #6730
    flux
    Member

    I don’t really know about the networking, but do note that TinyG supports up to 6 stepper motors; it just comes with four drivers. The two other are available on the board, you just need to add pin headers. You should be able to hook up a 3.3v-controlled stepper driver to those. I haven’t done this either, but it would seem pretty straight-forward, at least if proper caution is taken :).

    Probably cheaper and less complicated way to go.

    September 8, 2014 at 4:19 pm in reply to: Losing steps? #6728
    flux
    Member

    I too own a Shapeoko 2, so I must ask 🙂 : have you checked if the belts are ok? Not just that they are tight but that they are not broken. I once wondered why my X axis was not keeping its position and turned out that I had broken the belt. And I’ve done it to my Y axis as well.

    I noticed that the broken belts were dark from the broken area (some metal could be seen) and when placed tooth-by-tooth with a working condition belt, the teeth did not line up.

    I’ve changed the belts maybe twice so far, I guess it’s its way of telling that I can reduce motor current..

    July 21, 2014 at 4:13 pm in reply to: VFD Speed control. #6450
    flux
    Member

    I designed a board with this goal in mind. Its Eagle files are here:

    https://github.com/eras/TinyG-VFDController

    HOWEVER, I failed :-). It appears my circuit for controlling the analog input of the VFD doesn’t carry enough current, so the effect the RPM output has on the analog input of the VFD is a bit lame – I was never able to reach the full speed of the spindle with this. I used 100kHz as the PWM frequency.

    But at least the spindle on/off function works, which is quite convenient. I hope also that the vacuum cleaner relay control works, but I’ve considered adding a few small resistors in series to the transistor array relay pins. In any case, using the transistor array instead of separate transistors was a revelation to me, the first revision of this board has quite a bit more components..

    If someone better designing analog circuits wants to lend a hand, please do :-).

    I’ve also considered the option of passing the PWM signal as-is to the VFD (via a transistor) and use its filtering mechanism to make it analog, but I haven’t looked into if it would have potential to work.

    July 8, 2014 at 4:31 pm in reply to: G28.2 command to auto-level a PCB? #6370
    flux
    Member

    Nice! And the PCB appears to be around 65 mm wide, so not big!

    Question for you? How are you then converting your auto-level data to adjust Z-heights in your Gcode?

    I don’t have a solution for that yet. I don’t have a height capture program either. Though the results you have seem to indicate it would indeed be worthwhile to implement it. I have some G-code manipulation code already written, but not this one..

    I’ve actually been trying to make a two-sided 60 mm x 40 mm PCB with 0.2 mm isolation and 0.4 mm traces but so far I have failed. I think my problems would be solved if I were able to use cutting depth 0.05 mm, so 0.28 mm height variations would definitely kill that plan.

    • This reply was modified 10 years, 5 months ago by flux.
    July 4, 2014 at 10:28 am in reply to: G28.2 command to auto-level a PCB? #6324
    flux
    Member

    Hello,

    The new G38.2 command available in the Edge firmwares is what you need. Ie:

    G38.2 Z-10 F50

    moves till the A limit switch (I’m not certain about this) connects or till it reaches Z-10, whichever happens first.

    This has a few nice features:

    1) It doesn’t mess with your offets, so you can still G0 Z0 to move the tool up
    2) It returns absolute position so you can use G10 L2 Px commands with it regardless in which coordinate system you are in
    3) It works for any direction, not just Z
    4) It works even if your regular stop switch configuration is normally-closed.

    I usually use the command for setting the Z offset of my work plane for PCBs just once (in the middle of the board) per tool (I use three tools for doing a PCB). I’ve done so small PCBs that it’s been close enough. Also I fix my PCB to the platform with two-sided adhesive from the whole area (not just the edges or corners), so it should help with the warping effect. However, it cannot help with the varying thickness of the PCB, I understand this can be a factor as well.

    This can also be used for general scanning of whatever objects, in particular if you have a touch probe. All we need is the software to do it ;-).

    May 12, 2014 at 12:39 pm in reply to: TinyG edge drifts on series of small movements #5907
    flux
    Member

    Uh oh,

    It seems my belts had loosened (probably damaged) while I was working on wood all Saturday, so if those results cannot be reproduced, I’m perfectly willing to believe that that’s the end cause :).

    So I’m pretty sure that in fact the dev/426.02 indeed is the final fix for this issue!

    While it seemed strange that the issue affected both my X and Y axis, it is quite possible that they are both similarly worn out, which would explain why moving the working area (with coordinate systems) seemed to remove the issue. (Switching X/Y coordinate signs altered the work position as well.)

    I don’t have yet enough belt for replacing all the belts – I’ll do it in one go – so I think I may not be able to proper testing until they arrive (earliest next week, the upper bound of the ETA is next month). But, I’m now seeing so small difference (probably in the range of <0.5 mm) that I’ll still try with the PCB.

    Thanks for all the hard work :-).

    May 12, 2014 at 3:54 am in reply to: TinyG edge drifts on series of small movements #5906
    flux
    Member

    I did some more testing.

    test23.gcode: converted test.21.gcode by flipping negative X coordinates to positive ones, all coordinates are positive. No drifting.

    test24.gcode: converted test.22.gcode by flipping negatiev Y coordinates to positive ones, all coordinates are positive. No drifting.

    Then I executed test.24.gcode again, but at another coordinate system at

    [g58x] g58 x offset            -220.000 mm
[g58y] g58 y offset            -200.000 mm
[g58z] g58 z offset             -82.000 mm

    where as the original coordinate system had been

    [g59x] g59 x offset            -170.000 mm
[g59y] g59 y offset            -200.000 mm
[g59z] g59 z offset             -82.000 mm

    Interestingly, running test.24.gcode in the coordinate system 5 (G58) resulted in drift. This would suggest maybe the machine has trouble moving at that point? But on the other hand, how both Y and X would have the same trouble at that point and both not have it at another? Alternatively it could suggest there is some indeterminism at play. I have not yet hooked up the microscope to get better readings on the drift.

    I did another run of test.21.gcode at

    [g58x] g58 x offset            -120.000 mm
[g58y] g58 y offset            -200.000 mm
[g58z] g58 z offset             -82.000 mm

    and I saw no drifting. Could it just be the machine or firmware..

    May 12, 2014 at 1:47 am in reply to: TinyG edge drifts on series of small movements #5904
    flux
    Member

    All the test cases I mention here are available at http://www.modeemi.fi/~flux/tinyg/ .

    As I told in the email, after the success with test.1.gcode on dev/426.02 I tried test.20.gcode and noticed that there is a small negative X drift visible after the test run, < 1 mm.

    So next I executed test.1.gcode but with the F2000 replaced with F100, so very slowly, to see if speed is a factor. It still worked fine. Then I removed the Z moves from test.20.gcode and increased the speed to F1000, but the drift persisted, so it seems speed is not the issue here (no clicking noises either). The modified test case is available at at test.21.gcode .

    Technically the difference between test.0.gcode and test.20.gcode could be that test.0.gcode has been generated with epsilon 0.00254 mm (meaning the generator creates no shorter lines than this) and test.21.gcode has been generated with epsilon 0.05 mm. I have not verified if the setting actually works as described. But it’s interesting if the ultra-short lines now work but it’s the still-quite-short lines that make the effect visible.

    Next I took notice of the curious fact that it’s always the X axis that is off and it’s (almost?) always off to the negative side. So what if we swapped the axis? So I swapped X and Y from test.21.gcode for test.22.gcode and tried again (twice). And indeed, it’s now the Y that drifts to the negative Y. (I also notice that there might be a veeery tiny X drift as well; there may have been such a similar Y drift with test.20.gcode as well but I could easily have missed it.)

    • This reply was modified 10 years, 7 months ago by flux.
    May 11, 2014 at 11:37 am in reply to: TinyG edge drifts on series of small movements #5902
    flux
    Member

    Here’s the original test file with Z-lifts: http://www.modeemi.fi/~flux/tinyg/test.1.gcode . If someone is testing this with non-default coordinate system (as I am) be aware that the file has M02 at the end of the job (end job, reset coordinate system).

    May 11, 2014 at 10:40 am in reply to: TinyG edge drifts on series of small movements #5901
    flux
    Member

    Hello,

    I replied to the email you sent me, I hope you were able to receive it :).

    test.7.gcode still fails for all firmwares I have tried. Master (can’t recall the revision, but latest as of two weeks ago or so), 412.10 and 412.11.

    Are there any other problems in 412.11 that you are aware of?

    Well, while testing this I’m -pretty- sure I maybe have seen a lone “moves to completely to the other direction” problem. But I don’t have a reproducible test case for this.

    Another more reproducible issue (but no reproduction test case) is that if I re-home one axis (say, with G28.2 Z0) the following moves may move to the opposite direction. (Ie. G91 Z-5 moves up, not down.) This is fixed by homing the rest of the axis as well. This is quite an interesting case, I should look into the exact reproduction recipe.. It could be that the probing command is related, as I use G38.2 quite often.

    May 7, 2014 at 1:22 am in reply to: TinyG edge drifts on series of small movements #5886
    flux
    Member

    Oops, when I mentioned edge version 412.10, I always meant 412.01!

    I should add that test.7.gcode typically drifted by around x:-10 mm while test.gcode much less, around x:-1 mm. (Both probably drifted in y as well but X is easier to notice.) The tests that work on edge but failed on master drifted about x:-10 mm as well.

  • Author
    Posts
Viewing 15 posts - 1 through 15 (of 31 total)
1 2 3