Ah, I was about to say "no, it's just 100x the accel, not 100x^2 the 
accel, we're just changing the time frame".

But I started to question myself and did the math logically. Duh.  YOU 
are right, I've had that all wrong.

That 25% gap seems troublesome.  Because, like I say, I need to use it 
to tune the params, but there's other factors at work here, which was 
kind of expected.  The concern is say I could sim  it and find trading 
off accel for velocity yields a 10% runtime improvement in sim, but in 
reality that's just a idiosyncrasy of stepping 100x faster and in 
reality maybe this change makes it 5% slower, not faster.  In that case 
it's foolish to try to tune with it.  Chasing unicorns.  You'd never 
know if you actually made it better or worse without a 1x run, making 
the sim useless.

Did you loopback the position command, or just disable the motors?  I 
wonder if the DIR_SETUP and DIR_HOLD are mucking with the accelerated 
timeframe.

Hey, wait- try changing the SERVO_PERIOD given to loadrt emcmot too.  
That should change *everything*.

So I heard the part about looping back the position command. Could we 
leave the vel and accel normal, let the motion component believe that 
it's running at its normal rate, but then run the motion component at a 
much faster rate than real time?  Hack the time base?

The motion component's EMCMOT, right?  My understanding is quite crude, 
but is it like a 1ms thread that just increments its own time counter by 
1ms every time it gets called?  If so then the answer would be to leave 
it believing it's on a 1ms time base but reschedule the thread execution 
for 0.01ms, or 0.001ms, or any number.  It will reliably sim could how 
many ms the program takes regardless of how often the thread executes.


I do see the loadrt loads emcmot thread at SERVO_PERIOD.  Of course 
there's no hook to change the concept of time inside emcmot from the 
scheduler, because it's not normally done.


I don't see how you could change it on the fly either.  I mean there'd 
be a VCP button for "switch to sim run" that could easily loopback the 
position command, but it would also have to tell the scheduler that 
emcmot thread needs to run at a much different rate and I don't know how 
you'd do that from VCP.

Danny


On 10/14/2016 1:32 PM, Todd Zuercher wrote:
> I seem to be having some success with this.  I have a simulation config set 
> up with max velocities set to 100x, and max accelerations set to 10000x, 
> feed-overide set to 100x.  Using my scaled timer set to 100x the estimated 
> run time seems to be pretty consistently about 25% too long for a 20 minute 
> engraving file, but a slow 1 hour long single move tests just right.
>
> So I increased the acceleration still further, until I started to get 
> runtimes approximately the same as an unscaled simulation.  I ended up with 
> the acclerations set to 20000x the original configuration that I am trying to 
> simulate.  It doesn't hardly seem right but is what seems to be working.
>
> ----- Original Message -----
> From: "Todd Zuercher" <zuerc...@embarqmail.com>
> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
> Sent: Friday, October 14, 2016 9:52:18 AM
> Subject: Re: [Emc-users] Hacking a sim runtime mode
>
> A quick stupid question, if i'm scaling time 100x, velocities should increase 
> 100x, but what about acceleration, should that be increased 10000x or 100x?
>
> ----- Original Message -----
> From: "Todd Zuercher" <zuerc...@embarqmail.com>
> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
> Sent: Thursday, October 13, 2016 9:30:34 PM
> Subject: Re: [Emc-users] Hacking a sim runtime mode
>
> I think you are probably right.  Running the simulation at 100x was much more 
> accurate than 1000x.  Tomorrow I'll have to play with the servo thread speed 
> some and see if and how much improvement I can find.  But not sure how much 
> improvement will be possible in a sim config on a VM.
>
> ----- Original Message -----
> From: "Stephen Dubovsky" <smdubov...@gmail.com>
> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
> Sent: Thursday, October 13, 2016 3:52:42 PM
> Subject: Re: [Emc-users] Hacking a sim runtime mode
>
> I think the error of this approach (using N times higher accel/vel) is
> coming from the piecewise linear approximations of the curves going bad.
> If you try to follow a curve N times faster, then there are N times fewer
> samples along that curve for a fixed time sampling period.  That introduces
> errors.  There may be others but thats at least part of it.  Its the same
> problem w/ discrete time vs continuous time systems.  There is divergence
> between the solutions as the sampling rate goes down.
>
>
> On Thu, Oct 13, 2016 at 3:08 PM, Todd Zuercher <zuerc...@embarqmail.com>
> wrote:
>
>> I was just working at this a little bit.   The first thing I did was to
>> modify time.comp, to make a new sim_time.comp.  The sim_time.comp is
>> basically just the same as the regular timer component with an input pin
>> added to scale the time to what ever factor you speed up the simulation
>> run.  Then I made a dummy config of one of our machines with all the
>> velocities and accelerations increased by 1000x, and test ran a few things,
>> the results were not quite as good as I had hoped, but were way better than
>> the old estimations. Is it possible that some of the inaccuracy came from
>> the fact I was running it in a VM?
>>
>> The timer scaling pin was a really simple mod, would there be any interest
>> in adding that to the regular release?
>>
>> ----- Original Message -----
>> From: dan...@austin.rr.com
>> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
>> Sent: Thursday, October 13, 2016 2:24:53 PM
>> Subject: Re: [Emc-users] Hacking a sim runtime mode
>>
>>
>> ---- Chris Albertson <albertson.ch...@gmail.com> wrote:
>>> On Thu, Oct 13, 2016 at 9:00 AM, Peter C. Wallace <p...@mesanet.com>
>> wrote:
>>>> On Thu, 13 Oct 2016, dan...@austin.rr.com wrote:
>>>>
>>>> I just tried a real time Mesa Ethernet config with maxvel = 120000 IPM
>> (2000
>>>> IPS = 20 MHz step rate at present 10000 steps/In scaling) and maxaccel
>> 20000
>>>> IPS/S (52 Gs) with a 1 KHz servo thread, and it works fine (Peak
>> following
>>>> errors in the 1-2 mill region)
>>> The problem to be solved is getting an estimate of the time required
>>> to complete a job.   Does the above do this accurately?
>> Yeah I want to know this.  I can run a job for real vs "fast sim" and
>> compare.  One prob is the cycle time only goes down to seconds AFAIK.  If
>> it's 100x then that's over a minute and a half it could be wrong, but
>> that's still good enough as long as it's not estimating a very short job.
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to