I stripped the config bare, except for motion, and the timer component. had the command connected to the feedback, to try to get as little cpu overhead as possible. I tried setting the thread speed to 10000, and it didn't make a difference. But by jacking up the acceleration, I think I was able to get reasonably accurate sim times.
You or some others should give it a try and see what you think. Especially if you have some very long files you have ran before, with known runtimes for comparison. Modifying time.comp was very simple. (I think I only added 1 lines of code and modified another.) ----- Original Message ----- From: "Danny Miller" <dan...@austin.rr.com> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net> Sent: Saturday, October 15, 2016 1:51:42 PM Subject: Re: [Emc-users] Hacking a sim runtime mode 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 ------------------------------------------------------------------------------ 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
