Dual bipod winch foam cutter

More
11 Jul 2011 19:25 #11427 by bvandiepenbos
Thanks Andy, I appreciate you digging into the source so we can understand this better.
I took a brief look at the code as you noted, but am at office right now. When I get home I will review closer and report back.
~*Brian

Please Log in or Create an account to join the conversation.

More
11 Jul 2011 19:26 #11428 by bvandiepenbos
Thanks Rick,
when I get home tonight I will check into all these points and report back.
~*Brian

Please Log in or Create an account to join the conversation.

More
14 Jul 2011 17:51 #11532 by step4linux
andypugh wrote:

In practice actual step time isn't set by the stepgen step_len parameter, but by the parport reset_time parameter. There is a function of the parport driver where a programmable time after setting the pins to the new configuration it sets pins in the reset mask back to zero. stepconf uses this (line 805) as it means you can have double the step rate.

I´m the german fellow .... B)
just one comment: I use a home made board with a TBA6560 too, and I disabled the reset function, because the TBA6560 needs pretty long pulses. I think the hal, which is published at google code, is working with my TBA6560 hardware perfectly.

Gerd

Please Log in or Create an account to join the conversation.

More
14 Jul 2011 18:17 #11533 by andypugh
step4linux wrote:

just one comment: I use a home made board with a TBA6560 too, and I disabled the reset function, because the TBA6560 needs pretty long pulses.


It is worth noting that "Reset" actually freezes the machine in a busy-loop waiting for the time to expire. The driver limits the wait to 1/4 the base period. If you need more than 1/4 the base period then you probably need to increase the base period to suit the driver. This probably actually gives better step and cpu performance.

Also, if there are any other base-thread tasks to perform, they should be between the parport-write and parport-reset functions. You might logically expect to put (for example) the pwmgen make-pulses function before the parport-write, but you probably don't actually care about a 1-period phase lag in your pwmgen, and probably not in your stepgen either. (But I need to think harder about this)

Please Log in or Create an account to join the conversation.

More
14 Jul 2011 18:37 #11534 by step4linux
andypugh wrote:

It is worth noting that "Reset" actually freezes the machine in a busy-loop waiting for the time to expire. The driver limits the wait to 1/4 the base period. If you need more than 1/4 the base period then you probably need to increase the base period to suit the driver. This probably actually gives better step and cpu performance.

hi Andy, isn´t the "freeze" time specified by this hal line ?
setp parport.0.reset-time 5000
removing "reset" will remove the freeze as well, and the pulse length is equal to the base period.
CPU load is reduced, but the max pulse rate will be half of the one with reset.

Gerd

Please Log in or Create an account to join the conversation.

More
14 Jul 2011 18:44 #11535 by andypugh
step4linux wrote:

[
hi Andy, isn´t the "freeze" time specified by this hal line ?

setp parport.0.reset-time 5000

Yes. But if you exceed 1/4 of the base period time, then it uses a shorter time. I am not sure if that is documented, I saw it in the code.

removing "reset" will remove the freeze as well, and the pulse length is equal to the base period.
CPU load is reduced, but the max pulse rate will be half of the one with reset.


Indeed. My point was that on a low-latency machine with long-pulse drives you might get better step rate _and_ better CPU responsiveness by running a longer base period with reset than a short base period without it. Or, depending on how the reset time fits in to your other thread contents, not.

Please Log in or Create an account to join the conversation.

More
15 Jul 2011 05:10 - 15 Jul 2011 05:41 #11538 by bvandiepenbos
Rick G wrote:

Brian,

Just to avoid any further confusion on our part you have ..

Run Latency test for an extended period.
Taken the results of the Latency test and the timming praramters for your drivers and run them through Stepconfig on ficitious machine.
Taken these results and checked/editied your machine configuration.
Tried these and checked if the Scale is right (command 1" movement and machine moves 1")
Checked to make sure you are appling the correct amps to motors.

And motors run but not smooth.

Rick G

-yes latency test ran, max jitter is 26000
-created fictitious machine and edited my config with fictitious results
-scale is not right, 100mm G0 mdi move gets...
X= 70mm V=120mm
Y= 180mm U=80mm
(these are approximate, eyeballed with tape measure)
-amps set OK
-yes motors run but not smooth or fast enough

here are some specs of my setup;
motors are 200 steps/rev
motors are 6wire, only 4 used (center tap of each coil is not connected)
board set to 1/2 micro step
winch spindle diameter = 1 revolution winds up 25.4 mm of cable
spindle is directly on motor shaft, no other belts/screws
distance between winches is 762mm
the scale stepconf of fictitious machine gave me is 15.748031

~*Brian
Last edit: 15 Jul 2011 05:41 by bvandiepenbos.

Please Log in or Create an account to join the conversation.

More
15 Jul 2011 05:21 #11539 by bvandiepenbos
andypugh wrote:

bvandiepenbos wrote:

I am still confused.


I have been looking at the stepgen source, and I am now a little less confused.
git.linuxcnc.org/gitweb?p=emc2.git;a=blo...1742086cfbb5;hb=HEAD
Line 709 onwards.

Basically stepgen chooses a base period such that the period is long enough to not need more than one thread period per step. This makes sense, as the base period can be adjusted to nanoseconds, whereas if you are using multiple thread periods per step the resolution is in tens of uS. Whilst step_time is nominally in nS, setting it to 1 just means that it is set high when stepgen runs and there is a step request, and then low next thread execution.
In practice actual step time isn't set by the stepgen step_len parameter, but by the parport reset_time parameter. There is a function of the parport driver where a programmable time after setting the pins to the new configuration it sets pins in the reset mask back to zero. stepconf uses this (line 805) as it means you can have double the step rate.

The setup and hold time parameters are calculated in line 719/720 and seem to be the number you put in the boxes + the latency you put in the latency box. Does that fit?


Andy,
yes that fits, I put in latency of 26000 and 1000 in driver timing = 27000, which is value in .hal for dirhold and dirsetup

my base period is 100,000
servo period is 1,000,000
traj period is 1,000,000

~*Brian

Please Log in or Create an account to join the conversation.

More
15 Jul 2011 05:37 #11540 by bvandiepenbos
step4linux wrote:

andypugh wrote:

In practice actual step time isn't set by the stepgen step_len parameter, but by the parport reset_time parameter. There is a function of the parport driver where a programmable time after setting the pins to the new configuration it sets pins in the reset mask back to zero. stepconf uses this (line 805) as it means you can have double the step rate.

I´m the german fellow .... B)
just one comment: I use a home made board with a TBA6560 too, and I disabled the reset function, because the TBA6560 needs pretty long pulses. I think the hal, which is published at google code, is working with my TBA6560 hardware perfectly.

Gerd


Hello Gerd, thanks for your input to this thread.
I really love your hotwinch machine, very clever!
Sure hope I can get my machine working.

I have another question about the TB6560...
my board has a setting called "Decay Mode" do you know what it does?
the choices for Decay are; Fast, 25%, 50%, or Slow
any guess as to what setting to use?

Thanks,
~*Brian

Please Log in or Create an account to join the conversation.

More
15 Jul 2011 06:02 #11541 by bvandiepenbos
Gerd,

I don't understand some of values in the .ini

# kinematic definitions for dualbipod
# D01: distance between joints 0 and 1
# D67: distance between joints 6 and 7
# XU0: reference point, X and U coordinate
# YV0: reference point, Y and V coordinate
# If you execute "HOME" (Referenzfahrt), the result will be:
# X = XU0, Y = YV0, U = XU0, V = YV0
[KINEMATIC]
D01 = 762.0
D67 = 762.0
XU0 = 120
YV0 = 0

how do I measure the XUO and YVO?

I understand the D01 and D67 are distance between winch motors (mine are 762 mm center to center of shafts)

Thank you,
~*Brian

Please Log in or Create an account to join the conversation.

Time to create page: 0.101 seconds
Powered by Kunena Forum