Re: Fw: Stg2, 2- problems



Jan,

I manually added you to the emc-at-nist.gov mailing list. Sorry, I should
have done this long ago. Your name won't appear on the published list of
subscribers for about a day, but you can begin to post immediately.

You wrote:

> Input_scale left to 1000 so 1count=0,001mm. (with units set to mm or
> inch it always gives the same result?)

If you set UNITS = 1.0 for the [TRAJ] and [AXIS_#] sections, this makes
your user units millimeters. Then, for INPUT_SCALE, the first value
should be whatever encoder counts equal 1 mm. The second should be 0,
since it's not used in the .ini file for servo machines.

I think I tested this and it worked, but I'm not sure so you should try
it and let me know what your symptoms are.

Also:

> Encoder 1,3 and I presume 5 and 7 gives out, flipping values between
> the exact counts and counts * 65537. So a movement of 0,001mm gives
> out the value of 1 and 65537, a movement of 0,002 gives out 2 and
> 131074... This can be seen on the original STG-module and with
> stg2diag. The latter gives whit every flip a linefeed so the values
> can be easily read. The value 65537 can be interesting; as 2 to the
> power of 16 + 1 = 65537. I don't know of this problem is only
> encountered with my board but I will ask STG if they know this problem
> yet.

I've never seen this. You need to be sure that the power supply that
powers the encoders shares its ground with the Servo To Go digital
ground. Otherwise, ground loop problems will cause noise and
unpredictable feedback. If you're sure of the elcctrical hookup then the
STG folks may be able to give you some pointers. Let me know what they
say. Post to the emc-at-nist.gov mail list so others can see; I'm always
surprised at the experts in the field who know more than I do about my
software.

> Second problem is that with only axis 0 and 2 attached (the good ones)
> Xemc, TKemc or emcPanel can't follow the reading of the encoders with
> movements higher than 500mm/min.  The readings aren't updated anymore.
> When slowing down the speed they become (after a while) updated
> again.  Can this be a timing problem ( I tried to change al the cycle
> values, but without any success) as stg2diag even with G0 (2,2 m/min)
> always shows the exact values?

I've never seen this before. You should have the [AXIS_#] CYCLE_TIME
values set to something like 0.00100 (1 millisecond), the [TRAJ]
CYCLE_TIME set to something like 10 times the axis values, e.g., 0.010
(10 milliseconds), the [TASK] and [EMCIO] CYCLE_TIME values set to
something like 10 or 100 milliseconds (0.010, 0.100), and the [DISPLAY]
CYCLE_TIME value set to about 200 milliseconds (0.200). I don't see how
the speed of the machine can affect the GUI updating.

You can run the "usrmot" motion controller utility when the whole
controller is up, or just if the motion controller is loaded. If you
just load the motion controller, you can send its .ini file parameters
down to it using the "inimot" utility, like this:

you> cd /usr/local/nist/emc
you> insmod plat/rtlinux_09J/lib/stg2mod.o
you> plat/linux_2_0_36/bin/inimot -ini yourfile.ini
(some messages saying initing axis #...done, or something like that)
you> plat/linux_2_0_36/bin/usrmot -ini yourfile.ini
motion> help
(shows terse help list)
motion> [ENTER] shows status
motion> enable
motion> show pids
motion> [ENTER] shows just the PIDs
motion> show times
motion> [ENTER] shows the min/max/average compute times
motion> show
motion> [ENTER] shows full status

--Fred



Date Index | Thread Index | Back to archive index | Back to Mailing List Page

Problems or questions? Contact