Am 18.07.2013 um 17:57 schrieb Charles Steinkuehler <[email protected]>:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/18/2013 9:33 AM, Michael Haberler wrote: >> I'd be interested in what was your biggest-sized G-code program >> ever >> >> good enough: file size, number of lines - just a rough indication >> is fine >> >> --- >> >> background: I am considering alternative internal representations >> of G-code and want to get a handle on the problem size > > Question: Would you design something in today's world that had any > sort of hard-coded limit (other than maybe native memory size)? no, and I'm not doing that anyway - dont worry;) > If so, why? The background of the thought experiment is: Many interpreters use some form of intermediate language (ever since Basic ;) which is essentially a syntax & semantics checked internal representation of a program; the LinuxCNC interpreter does so too, and it's name is the 'canon layer' One of the underlying issues with canon relating to this problem are: many decisions - like offsetting and CRC - are done very early in the pipeline; and given much source context is lost in the translation step, it is very hard to recompute certain motion commands with modified parameters. A higher-level intermediate form enables more choice as to where such binding is done and hence can be modified at runtime. There are tradeoffs in the choice as to the level of abstraction and relation to the source program when selecting an intermediate form; I consider the intermediate representation basically a 'make or buy' decision, meaning it is entirely conceivable to select an existing language as intermediate form. However, existing interpretive languages usually come with hard or soft size restrictions for parsing/compilation unit size; I am trying to gauge at which point input sizes might become an issue when choosing an existing language, and need addressing, for which there are strategies (at a cost: work *). Note input size:intermediate size isnt necessarily linear relation; for instance, if one were able to do Naive CAM detection before emitting intermediate form, that might have considerable impact on intermediate size. think of it as a 'canon intermediate language' as an alternative to a 'canon queue', which might have upsides relative to some issues which are hard to address in the current scheme, in particular RFL, checkpoint & restart execution - possibly somewhere with modified parameters (like offsets, tooldia), scripting of motion for other purposes than NGC execution etc. It's all blue sky. - Michael *) for instance, using mmap() on a file of intermediate language, which makes the size problem go away; cost: an existing interpreter likely needs modification. > I envision a future where gcode files are split into 1 Gig chunks > because Microsoft^H LinuxCNC can't handle files bigger than that(*). > > Also, if I'm not the only one seeing load-time issues with gcode > files, perhaps the validation and loading of a gcode file could be > split. I like validating the gcode, but don't feel like it's > necessary to perform that step every time I load the same file into > Axis to run a job over again. > > I was blaming the gcode load times on the "sluggish" 1 GHz ARM on the > BeagleBone, but it sounds like the gcode files for 3D printing are > towards the larger end of "typical" for LinuxCNC. > > (*) Obscure reference to the DVD format, and why it uses a collection > of 1G VOB files instead of a single large video file. > > - -- > Charles Steinkuehler > [email protected] > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlHoEFQACgkQLywbqEHdNFyqcwCfTsKFbs7hxhOj9aBNC6tXePh1 > 1ggAmQH9M1i0Ou5ikhvHRQmfieEyDvyr > =/Hpv > -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
