Travel per revolution Settings

Home › Forums › TinyG › TinyG Support › Travel per revolution Settings

Tagged: , ,

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • February 17, 2016 at 9:33 am #9352
    lightlapreset
    Member

    Hi Everybody!
    A co-worker of mine configured our tinyg very well. As I was unhappy with the maximum velocity I changed the VM and FR parameter to a lower value on Chilipeppr, which worked fine. A side effect of my change was that the travel per revolution was changed too, though i did not even make any changes there! The values remained the same (we compared screenshots of the settings) but it seems like the tinyg is working with an other value that is much higher… We made a factory reset and configured the tinyg to the exact same settings as before I made any changes but the travel per revolution still is not correct. We have been able to reproduce the problem when we sent the settings to tinyg from Matlab. The interesting fact is, that with either Chilipeppr or Matlab the settings are shown correctly but the tinyg is not working with them.

    Do you have any suggestions? Recent changes in the travel per revolution settings did not show any effect.

    Thank you very much!

    PS: Firmware Build 440.20

    February 18, 2016 at 5:29 am #9353
    lightlapreset
    Member

    Hey Guys, there somehow was a mistake in the shown settings before I did my changes. So the reset to the values we have seen in our screenshots were already incorrect. I quickly calibrated the movement of all axes to a precision of +-1mm which should be adequate enough for some testing.

    –> Problem solved

    February 18, 2016 at 6:49 am #9356
    cmcgrath5035
    Moderator

    How did you make the VM and FR parameters changes?
    From within CP, that translates to using the Serial Port Console and entering parameters one at a time, using the configuretinyG widget GUI to make changes, or perhaps using the Archive/Restore widget.

    Bottom line, avoid using the configuretinyG widget, it has caused issues for some folks. I recommend Serial Port Console, sent one at a time.

    It appears you have (or think you have) resolved your issue.

    Can you describe briefly how you implement changes via Matlab?
    Others have asked in the past similar question.

    February 19, 2016 at 3:38 am #9360
    lightlapreset
    Member

    The changes of the parameters were made one by one in CP using the console. I double-checked the settings today and they still are correct.

    The implementation of changes via Matlab works with a serial port object. I do not really know how to submit Matlab-code here, so I just write down the most important lines of my code:

    obj = serial(‘COM’,’BaudRate’,115200,’Parity’,’none’,’FlowControl’,’software’,’DataBits’,8); % Create a serial port object with the specified settings (these have to be the same ones as the settings of your tinyg). As ‘COM’ you have to write the COM-Port your tinyg is connected to.

    fopen(obj) % opens the com-port

    From now on you can send lines of gcode in json-syntax directly to the tying using fprintf. The changes of Motor 1 settings (in nested code) as example:

    fprintf(obj,'{“1”:{“”ma”:0,”pm”:3,”po”:0,”tr”:50,”mi”:8,”sa”:1.8}}’);

    You also can send the settings individually like:
    fprintf(obj,'{“1ma”:0}’);
    fprintf(obj,'{“1pm”:3}’);
    … and so on

    With fscanf(obj) you will read out the tinyg line per line.

    Don’t forget to close and delete the created serial object at the end with fclose(obj) and delete(obj) or you will get a complete mess trying to set up a new connection 😉

    February 19, 2016 at 8:57 am #9363
    cmcgrath5035
    Moderator

    Good thing you didn’t directly post Matlab, as I have not programmed using it in perhaps 20 years. So your description much more helpful

    Are you aware of, and ensured, that the implications of this Wiki section are accomodated in your code:

    On the chilipeppr side, we have determined that the best, and perhaps only way to make the bulk programming (multiple parameter) writes is to send a single parameter value, or multiple parameters via a json as you appear to be doing, then wait until a confirmation is received from tinyG before sending anything else. Both the configuretinyG widget and the ArchiveandRestore widget (see:

    ) use this methodology.

    You cannot rely on software flow control (I assume that means Xon/Xoff) to help here. I will also observe that I have seen individual parameter write cycles take 80 to 90ms, not <30ms, with a lot of variation.
    Folks who try to just dump a serial stream of parameters without watching the response channel typically wait a real long time, 500-1000ms, between parameters and claim success.

    To make matters worse, there seems to be evidence that jamming the channel with too many parameters and or too fast can corrupt other, some hidden, parameters in EEPROM. So doing just a read back of what you think you wrote is not adequate either.

    At the moment, the configuretinyG widget seems to be misbehaving and I am recommending that folks avoid it. We do not have a clear diagnosis.
    ArchiveandRestore, which uses the same return check mechanism, still works for me. A (major?) difference is that ArchiveandRestore sends parameters one at a time.

    We are way down in the weeds here, and may need to go deeper.

    I'll pause and get your feedback on what is already here.

    February 20, 2016 at 5:12 am #9366
    cmcgrath5035
    Moderator

    If you are familiar with Python scripting, you may want to review this parameter downloader:

    It may provide some hints.

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