Hi Alex! On 12.09.2014 19:03, alex chiosso wrote: > Hi Jon. > Thank you for the replay . > The part program is not so big (120 lines code , it is parametric style > with Named Parameters) so it is strange . > It is clear now the cpu hogg.
I don't know if it's really that easy. When you talk about "sim configuration", you mean one of sim INI files, i.e. those that do not require real hardware to be connected, right? I ask because there is something else that can also be viewn as "simulation" and this is the generation of the preview of the NC program. For this preview, the CPU executes the program as fast as possible, thereby simply calculating where the tool would be when running something like G0, G1, etc. This will usually cause 100% CPU load, but only during the time the preview is generated, which should not take longer than a second or so (at least for simple/short programs). But when you're actually running a program (in a sim configuration or on a real machine), the interpreter has to run through the program in the programmed speed, so that it can easily spend 10s in a G1 if it is long and/or slow. But most of the time, the CPU will just be idling and waiting for the next servo cycle during this operation. So the CPU load should be far below 100%, unless your computer is at its limits. > I did believe that the real time is always enabled also in sim mode. See above. "Real time" might not be the adequate name for the sim configurations, since they do not use/need the realtime kernel. But they should execute a program in about the same speed a real machine would. > Maybe this is why the hal file execution seems to have a sort of latency. > Can you explain me why only a part of the NC program is loaded (as you say > "only few K bytes"), what is the bottle neck ? There is no bottle neck, but it is good practise to always only process part of a program file. The reason is simple: If you have a reeeally big program (say, 100'000 lines of code or more), then it could take a considerable amount of RAM to keep everything in memory. And because such a big program is unlikely to run in only a second or less, it is sensible to always process only a small part of the file at a time. This is from a theoretical point of view. In practice, most current computers will have plenty of memory to easily keep even the biggest programs in memory at once. And, in fact, most GUIs will even do this, as they need to process everything in advance to draw the preview. Regards, Philipp > > > > > > On Fri, Sep 12, 2014 at 6:17 PM, Jon Elson <el...@pico-systems.com> wrote: > >> On 09/12/2014 05:27 AM, alex chiosso wrote: >>> Hi people. >>> I'm testing some NC code on a simulation configuration 3 axis . >>> I notice that during the NC program execution the pc is using the hard >>> drive . >>> As soon the program execution is stopped the hard drive is not used . >>> I believed that the NC program is loaded into the RAM memory so during >> the >>> NC program execution why LCNC should access to the harddrive ? >> No, only PART of the program is loaded into memory, if the >> program is >> longer than a few K bytes. >>> And another issue is that the cpu hogg (100% usage during NC program >>> execution) . >>> >> I think the sim mode goes as fast as it can through the part >> program, so >> it will always use 100% CPU. The sim mode has no concept of >> real time. >> >> Jon >> >> >> ------------------------------------------------------------------------------ >> Want excitement? >> Manually upgrade your production database. >> When you want reliability, choose Perforce >> Perforce version control. Predictably reliable. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk >> _______________________________________________ >> Emc-users mailing list >> Emc-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-users >> > ------------------------------------------------------------------------------ > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce > Perforce version control. Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users >
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
