how can I monitor the status of a homing operation?

Home › Forums › TinyG › TinyG Support › how can I monitor the status of a homing operation?

Tagged: 

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • October 19, 2017 at 9:46 pm #10645
    matthewdc
    Member

    (tinyG V8 hardware)
    Unlike the move commands, I can’t get a response to a query while the stages are homing. How do I know they are finished via software?

    Other observations I have a problem with:
    -In Coolterm I can get a ‘not home’ reply to $home immediately after reset, then after a G28.2 finishes, I will get a ‘homed’ replay to the same command.
    However, in my Labview code, I always have to run the homing sequence twice. After the first homing operation (after reset), I always get a ‘not homed’ status.
    I can’t see what I”m doing wrong.

    Another thing (in Labview): I can’t seem to grab all of the reply from $hom. When I query the amount of characters in the serial buffer then grab that amount, it is always just the first line. I have to keep reading the buffer to get each line. Can I just get the whole reply somehow?

    Another question about limit switches. Can I query the state of any of the homing or limit switches?

    All of these issues are draining my energy because I’m used to having no problem doing these with my other motion control projects. šŸ™
    thanks

    October 20, 2017 at 7:35 am #10646
    cmcgrath5035
    Moderator

    Query state of switches? in tinyG 440.20, I think answer is no, but need to dig out the whole answer. Perhaps in the new I/O implemented in G2core, some of which may be backported to tinyG in futurehttps://github.com/synthetos/g2/wiki/Digital-IO

    Can you describe how LabView interfaces to tinyG? Serial port (USB) direct connect, or via an intermediary (e.g. SPJS). Baud rate, flow control, etc?

    October 20, 2017 at 1:40 pm #10647
    matthewdc
    Member

    thanks for your reply cmcgrath5035

    For homing, right now I have fallen back to simply delaying long enough for the stages to finish before using the $home. It seems like I discovered I will get a ‘Homed’ reply but I still haven’t worked out how that happened.
    Is this the only way to monitor homing progress?
    I also noticed that even if I home just one stage that $home (or $hom) will say ‘homed’ even though the other two stages haven’t been homed yet.

    The reason I wanted to monitor the homing switch in particular is because I can use that to switch directions of the homing move, depending on the initial value of the switch. (the homing signal from this rotary stage is high for half of the range and low for the other half). Otherwise homing may take as much as 359 degrees to find the homing spot.

    As for Labview, I’m using the USB port serial protocol to simply pass ascii (text mode, not JSON) that I’m used to using with other stages/controllers. I query the serial port for how much in the buffer and read that out. I thought that handshaking may be throttling the data being sent but when I changed it to ‘no flow control’ in labview it made no difference. Perhaps I need to do the same on the tinyg side?
    I see that Coolterm receives the whole list of data (for $hom) but maybe there is some back-and-forth in the background I’m not aware of.

    Serial settings: 115200 8N1, handshaking set to both XON/XOFF and RTS/DCD(?) on both TinyG and the Labview serial port.

    • This reply was modified 7 years ago by matthewdc.
    October 21, 2017 at 1:51 pm #10649
    cmcgrath5035
    Moderator

    Homing: I sort of understand your objective but believe it is incompatible with how the homing command works. The most prevalent use for tinyG ia XYZ milling machines, with support for rotational axes as well but few well defined use cases.
    Many users implement only X,Y homing, no Z switches. There is only one homed state, yes/no. So issuing a G28.2 homes specified axes, assumes axes not on the list are not home-able (no switches) and sets the homed state if the specified axes complete successfully.
    It is not clear to me how to make it work for your use case.

    LabView and I/O – When you say ” I query the serial port for how much in the buffer and read that out. “, are you referring to the Labview receive serial buffer or the tinyG transmit serial buffer?
    There is no “some back-and-forth in the background Iā€™m not aware of.” beyond Xon/Xoff or RTS/CTS hardware level flow control on the tinyG side.

  • Author
    Posts
Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.