JuKu

Forum Replies Created

Viewing 15 posts - 16 through 30 (of 61 total)
1 2 3 4 5
  • Author
    Posts
  • December 15, 2014 at 7:15 am in reply to: File not open error #7187
    JuKu
    Member

    I converted the communications to be all JSON. The error stays.
    Also, it is not timing dependent; if I pause between commands or give them manually, it still crashes.

    Alden, what might cause “file not open” error?

    December 12, 2014 at 10:00 am in reply to: File not open error #7154
    JuKu
    Member

    > Did you hand edit the {“zsn”,0} JSON command into the Gcode file (to turn off the limit switch) ?

    No, but I wrote the program that is talking to TinyG. I’m not sending a file, my program is talking to TinyG in real time. At this point, it is trying to probe down (in my case, to +Z direction), therefore it is changing the switch settings.

    > When the GCode is being sent, I believe tinyG is in text mode.

    Doesn’t seem so; at least the responses are in JSON. Anyway, sending the switch command in text mode gives the same error.

    The error does not seem to depend on JSON vs text mode.

    December 12, 2014 at 5:46 am in reply to: Movement Issues After Homing #7151
    JuKu
    Member

    Double check that your min switch goes to min and max to max, and not vice versa. It is some time ago so my memories a vague, but I remember mine behave something like that before I fixed this.

    October 29, 2014 at 3:29 pm in reply to: Alignment correction? #6951
    JuKu
    Member

    It is a pick and place machine, so thete are no loads to talk about, and that ia likely a big factor. The work area is 370 x 580 mm, and movements are reproducible to 0.1-0.15mm. GT2 belt driven, software slack compensated. So, when I move 500mm, there is 0.65-0.8mm sideways movement. I can measure better than 0.1mm, but I don’t know how much better.

    I’ll see if I can implement this on my system driver level. Even if I might be able to do this, this might be useful in general.

    • This reply was modified 10 years ago by JuKu.
    October 9, 2014 at 2:16 am in reply to: Attempting to control with an arduino, Now Nothing #6867
    JuKu
    Member

    I’m not quite clear what you are trying to do, but in general: If you are doing programming on Atmel, a JTAG debugger/programmer is essential. Like, if your time is worth $0.50/h, it is still worth it.

    September 20, 2014 at 6:32 am in reply to: Networking two TinyGs #6784
    JuKu
    Member

    This is the official standard: http://www.ssl.berkeley.edu/~dseitz/MAVENflightPCBdesignAndFab/SMEMAfiducialSpec3p1.pdf

    September 19, 2014 at 2:48 am in reply to: Networking two TinyGs #6777
    JuKu
    Member

    Assuming you asked me:-),

    > Can you shoot me a note as to where you are physically located?

    Tampere, Finland.

    > if you are using fiducials to align what the camera is seeing with the real world of the CNC domain. If so, how do you do it, what fiducials are you using, and how did you fabricate them?

    I’m using industry standard fids, a round pad with no soldermask and no hole. On CAD, those are just another SMD component, with position data, manufactured by the PCB maker. At pre-processing, I find these from the pick-and-place file. I have a jig on the table where the board goes, so I know approximately where the board origin is in cnc coordinates. I go look at the fiducials, and regognize them using AForge.NET vision library to get the exact fid positions in cnc units. Then just some math to get board offset, scale and skew, which then give me the true component locations and rotation in cnc units.

    Of course, I also need to know the needle point offset from the camera, as a function of rotation. For this, I use another camera, looking up from a hole in the table.

    This has nothing to do with networking TinyG’s anymore. We can start another thread or take this off-line. (There are no private messages on this forum?)
    My mail is juha <at> kuusama point com.

    September 17, 2014 at 2:38 am in reply to: Networking two TinyGs #6761
    JuKu
    Member

    Talking about pick and place and vision, I am working on a TinyG based machine: http://hackaday.io/project/1755-LitePlacer—a-low-cost-Pick-and-Place-machine
    There is a video showing needle calibration. I haven’t updated the project, but the contraption actually picks and places. I use vision for machine homing, fiducials recognition (nominal to machine coordinates transform), parts pickup (no feeders, locating parts by looking at tape sprocket holes), loose part pickup, camera to needle and other calibration and rotation angle – needle position offset measurement. Pretty obvious how the four motor drives of TinyG are used. 🙂

    • This reply was modified 10 years, 2 months ago by JuKu. Reason: Link did not show up
    August 19, 2014 at 9:31 am in reply to: Help for debugging probing, please? #6649
    JuKu
    Member

    > I.m not sure why you went back (from?); tinyG FW supports NO or NC switches.

    The edge version has a bug, homing does not work on NO switches – or I am missing something again. Once I can home my machine, I’ll move right away.

    August 19, 2014 at 9:25 am in reply to: Testing Edge Builds 435.xx #6648
    JuKu
    Member

    Found it. Older version of the firmware did obey $me/$md even when $_pm was set to 0. I am using a settings dump that load my settings to TinyG after firmware update; that had individual motor power managements turned off, which still allowed global power management. Sorry for the false alarm. (I updated Github also.)

    August 18, 2014 at 10:21 am in reply to: Testing Edge Builds 435.xx #6636
    JuKu
    Member

    Also, $me/$md don’t seem to do anything. (435.10)

    August 18, 2014 at 10:05 am in reply to: Testing Edge Builds 435.xx #6634
    JuKu
    Member

    Homing does not work on NO switches. 🙁

    December 28, 2013 at 4:34 pm in reply to: Rotary axis hardware or software? #5102
    JuKu
    Member

    I have a TinyG based four axis machine. The gcode is built by a custom program. Works fine. What do you want to know?

    December 17, 2013 at 7:20 am in reply to: How to reset TinyG? #5087
    JuKu
    Member

    Also worth checking: USB devices dometimes renumber themselves. In other words, check that serial port number is still correct.

    October 31, 2013 at 4:10 am in reply to: Inconsistent homing results #4901
    JuKu
    Member

    Since I have an active thread about homing results, my results might be of interest: We found a bug, but when TinyG is used as intended, the results are not bad. I got new battery to my caliber, and run some experiments:

    Common factors: 8 microsteps, lever based good quality switches; lv= latch velocity, about twenty tries on each setting:

    Z axis, linear screw stepper, 8mm/rev, 1.8deg. step:
    lv 50: homing repeatibility < 0.01mm (under my caliber resolution)
    lv 100 – 500 (still within no bug area, but on the fast side): +0.05 .. -0.05 mm
    lv 1000: +.10 .. -0.10 mm

    X&Y axis: belt driven system, 40mm/rev, 0.9 deg. step. Here, I did not encounter the bug; slow setting is the intended use, fast setting the “stop whenever you can” case:
    lv 1500 (definitely in the fast area): +0.15 .. -0.15mm
    lv 500 (borderline area): +0.05 .. -0.05mm
    lv 100 (slow): under caliber resolution

    The absolute home postion is different in each case. Imo, this is of no importance. A CNC machine is a combination of mechanical design and control electronics settings. If you change something, it is expected that physical things change as well (like where the gantry really is after homing).

    Conclusions: It pays off to use the system as the designer intended. 🙂 Lever switches can be very repeatable, at least when relatively new.

    So, to the contrary to the thread title, homing results are actually very consistent.

  • Author
    Posts
Viewing 15 posts - 16 through 30 (of 61 total)
1 2 3 4 5