TinyG feedback

Home › Forums › TinyG › TinyG Support › TinyG feedback

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • October 26, 2015 at 12:30 am #8868
    Bill
    Member

    Hi,

    I have several questions about TinyG feedback:

    1. Does TinyG have the command that can report the current position?

    2. What are the meaning of 31 and 32 during homing report?
    ({“qr”:32} {“qr”:31})

    3. My zero backoff is 10mm, sometimes it only traveled only 3-4mm after motor release the latch and reported homed, this is going to make the incorrect action. How can I detect this homing error problem and how can I avoid this problem?

    Thanks!!

    October 26, 2015 at 4:12 pm #8869
    cmcgrath5035
    Moderator

    This item may help

    Lots of info spread around other wiki sections

    October 27, 2015 at 2:36 am #8870
    Bill
    Member

    Thanks a lot!!

    October 29, 2015 at 6:50 pm #8871
    Bill
    Member

    How to set TinyG always report text mode? Any commands?

    October 29, 2015 at 11:16 pm #8872
    cmcgrath5035
    Moderator

    Make sure $tv=1

    Sending $ej=0 should put tinyG in text mode.

    Are your wanting tinyG automatic status reports in text mode?

    Are you running Chilipeppr?
    Since CP makes extensive use of JSON , it is unlikely you can get text mode status, since CP is aggressive about keeping tinyG in JSON mode.

    October 30, 2015 at 12:13 am #8873
    Bill
    Member

    I am using Labview to design operating interface, I found TinyG sometimes return text report, sometimes return JSON report. I want to fix it in text mode, so it is convenient for me to programe.

    Thanks for your answer!!

    October 30, 2015 at 12:55 am #8874
    Bill
    Member

    the command $ej=0 need send to TinyG every time when TinyG powered on or only once?

    October 30, 2015 at 11:45 am #8876
    cmcgrath5035
    Moderator

    If you play with CP at all, you see CP/SPJS sending $ej=1 after every command, as a means of keeping tinyG in JSON mode.

    I suspect that JohnL found, by experience, that some commands left tinyG in text.

    I am not sure what correct answer to your question is, but would suggest $ej=0 after each command gets sent would be advisable.

    November 9, 2015 at 1:40 am #8916
    Bill
    Member

    How can I get the position of the homing switch pressed from the TinyG feedback?

    November 9, 2015 at 6:08 am #8918
    cmcgrath5035
    Moderator

    I assume you have reviewed wiki information such as

    Assuming you are using a G28.2 command to initiate homing, you could send a status request to tinyG next to read the position in the appropriate coordinate system.

    If a given switch is activated as homing only, with for example $xsn=1, that switch is only active when a homing cycle command is executed. If $xsn=2 or 3, limit or limit and homing, the switch will act as a limit switch except when a homing cycle is initiated by command.
    If the switch is activated when NOT executing a limit cycle, the switch activation will be interpreted as a limit action, immediately halting tinyG and recoverable only by reset, which will reset the current position of tinyG to 0,0,0.

    November 9, 2015 at 10:10 pm #8922
    Bill
    Member

    Thanks for your answer!

    Yes, we use G28.2 command to initiate homing.
    What we want to know is the coordinates for each axis at the exact instant when the homing switch is just being pressed. It appears that, the TinyG sends the coordinates for each axis periodically AND at the instant when the homing switch is being pressed and released. However, we are not sure how to tell which coordinates correspond to the instant at the time of the homing switch being pressed. If you could provide me the instruction to retrieve the coordinates at the instant of homing, we can then retrieve the correct coordinates to perform a check for the homing action.
    It appears that TinyG sent back string “qr:31” right after it sent out the coordinate at the instant when the homing switch is pressed, and sent “qr:31” again right after the switch is released. Please confirm if this is the case, and if I could use this info to determine the coordinates for homing, either at the instant when the switch is being pressed or released.
    Please also advise what “qr:32” means.
    The following texts are an example of the texts that TinyG sent back during homing:
    ———————————————–
    posx:-7.441
    posx:-10.639,vel:799.96
    posx:-11.497,vel:0.04
    qr:31
    posx:-11.268,feed:60.00,vel:60.00
    posx:-11.028
    posx:-10.784
    posx:-10.539
    posx:-10.294
    posx:-10.054
    posx:-10.000,vel:0.13
    qr:31
    posx:-7.618,feed:800.00,vel:800.00
    posx:-4.370
    posx:-1.122
    posx:-120.000,vel:0.00
    qr:32
    tinyg [mm] ok>
    posx:0.000,feed:0.00,vel:0.43,coor:1,dist:0,stat:5
    qr:31
    tinyg [mm] ok>
    —————————————————————-

    November 10, 2015 at 7:01 am #8923
    cmcgrath5035
    Moderator

    Bill
    I am not a programmer for tinyG at the level you are targeting, but use questions like yours to dig in and find out when possible.
    I suggest you have a look here:

    There is a lot of good info in the Wiki, but can be difficult to find. I find this search add-on to be very useful. You need a (free) github login for the tool to work properly, I believe.

    So searching the wiki for ‘qr’, I found this

    which should answer your qr question.
    By the way, I would not assume that tinyG sends a status report synchronized to the homing switch operation. If it did, it would report position = 0 in the G53 coordinate system.

    I assume you have read all there is to read in the wiki on homing cycles.
    Referencing this

    My read of this reference says that as each axis is homed, the position of the machine will be = [the physical location of the switch] + Zero Backoff and the G53 coordinate for that axis will be zero.
    So, for example, when a G28.2 command completes, the X axis will be at 0 and the switch location will be -$xzb, both in the G53 coordinate system.

    The X position of the machine just prior to the homing switch operation (pressed) will be a value that is relative to some arbitrary point where the machine was last homed or tinyG was reset, which says to me that would not be a useful value to you.

    That help?
    Note that the Wiki Comments:

    Note: In high-end CNC machines there is often no user-accessible homing cycle as machine zero is set at the factory and does not need to be set by the end user. See Peter Smid’s CNC Programming Handbook, version 2 for details.

    November 10, 2015 at 10:05 pm #8924
    Bill
    Member

    Hi,
    Thanks for your reply.
    Regarding your remark:
    “The X position of the machine just prior to the homing switch operation (pressed) will be a value that is relative to some arbitrary point where the machine was last homed or tinyG was reset, which says to me that would not be a useful value to you.”
    In fact, This is very useful to us. Please let me to explain.
    I understand that when a G28.2 command completes, the X axis will be at 0 and the switch location will be -$xzb. But because the TinyG runs in open loop, it doesn’t know for sure if the XY table move to the required position accurately or not, as the actual table movement will be affected by motor, pulley and belt, etc. Thus the switch may not be at -$xzb as what TinyG thinks to be. So to have an idea if the XY table maintains the sound accuracy, we are hoping to read the homing switch position at each homing event, either at the time of the switch being pressed or released. Because once we establish an accurate homing switch position, we can use is as a reference for each homing in a volume production condition. If the variation of the homing switch position against the reference is outside a predefined threshold, it will be an indication of some system errors that have caused this variation, such as a loose pulley, etc.
    Is there any command that we could use to find the position (coordinates) of the switch at each homing event? As listed in my previous email, the TinyG does seem to feedback the switch positions, both pressed and released, which shows that the TinyG knows exactly those events. It will be great if you could tell me how to retrieve the homing switch coordinates at each homing event reported by TinyG.

    November 11, 2015 at 9:31 am #8928
    cmcgrath5035
    Moderator

    Bill
    Thanks for your expanded description of your objective. What you describe is in fact what I assumed you were attempting to implement, so we are relatively in synch with this discussion.

    Here is how I would ask this question of the developers:

    ” During a G28.2 homing cycle, can a status report be generated that reports the axis position at the instant a homing switch is operated, before the position value is reset to = 0 as the axis completes homing clcle.

    Use Case: Consider a homing cycle initiated when a previously homed machine is at arbitrary position X1, Y1, Z1. The value of X position when the $xsn operates should be (-$Xlb) if the machine has been perfectly tracking since the original homing cycle. If not, the machine has drifted and requires maintenance ”

    If you understand and agree with this wording ( a bit clearer at least to me what you need), post (or modify and post) the question here:

    That is where the developers hang out

    Assuming you can get the position information you desire, keep in mind a couple of obvious error sources that you will have to deal with:
    A. The difference between mechanical operate/non-operate position in your homing switch. The zero point is actually $xzb away from the non-operate point, but you would get the operate point from the status.
    B. The accumulation of moves smaller than the finite resolution of the machine(the distance each axis moves when a step is sent to the motor controller)

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