[Aptos-devel] Fwd: APT360 XML Clfile ???

[Brent M. <bre...@gm...>]

Here is a discussion that Phil emailed me about that I thought the list
might be interested in.

Also, Jim brought up the intriguing possibility of using the READ/2
statement to read in dxf files, among other things.

Any comments would be appreciated.
Brent.
---------- Forwarded message ----------
From: Rusk County Manufacturing LLC <rc...@br...>
Date: Thu, Nov 19, 2015 at 5:32 PM
Subject: Re: APT360 XML Clfile ???
To: Brent Muller <bre...@gm...>


Fine with me to forward it to the list.

I'm ok with using other languages besides C for the external tools like the
posts.

I should try some Python, maybe writing a app that demonstrates how to
access / use an XML clfile would be a good project to start with.

I like keeping the posts 'out of the kernel' but being able to invoke them
with a late binding scheme could be an improvement versus launching a
separate process, at least on Windows.

I seem to recall running into a few instances where launching / tracking
the postprocessor process instance got out of sync but that could be me /
Windows. Implementing a late binding scheme in Windows is simple but am
clueless about Linux, it looks something like this (less error checking):

        // Load user's post dll. Convention would be 6 char max name from
MACHIN
        // stmt plus '.dll' file extension.

        HDLL hdll = LoadLibrary("postp.dll");

        // Get function pointer to user's 'standard' APT360 entry point
        // we'd have to agree on a 'standard' function name for the
        // postprocessor entry point.

        (function pointer type)* pfn = GetProcInstance(hdll,"PostPMain");

        pfn(arglist); // launch user's postprocessor code

        FreeLibrary(hdll);

As I recall, the Windows security officers dislike user processes launching
other processes ;-)

A bit of support code that would act as the EXE to launch the user's DLL
for post developers without having to have a full APT development setup is
also just a few lines of code in Windows.


On 11/19/2015 4:12 PM, Brent Muller wrote:

> I think it is a great idea. There wouldn't be any downsides to lowering the
> entry bar for newcomers. The author of vapt actually parsed the text std
> out to
> get geometry data for his program. I don't know if this was before or
> after I
> created the binary "print.tap" file for geometry.Regardless, the binary
> file
> wasn't documented, and required a person to sort through hundreds of lines
> of code.
>
> Speaking of print.tap, it might be a good idea to have a text print file
> also.
>
> Although it isn't a requirement, it would be nice to keep the dependencies
> low.
> Right now, the code compiles easily for most people. I don't know what
> libraries
> you plan on using, but that is also a barrier to entry for newcomers, to
> compile
> and install libraries. But if you have code already, don't worry about it.
>
> I have been thinking about moving the postp code into the main package.
> What
> would you think of that? Again, it would make it easier for people to get
> started.
>
> Have you programmed in Python before? I made the postp code in python
> because
> most of the LinuxCNC people are pretty familiar with Python, and I
> expected them
> to want to tweak the posts. I only mention this because it fits well with
> the
> theme of barrier to entry that you rightly point out, and something that is
> increasingly on my mind. I also think that Python dependencies would be
> easier
> for newcomers to install than C libraries.I know you are a good C
> programmer,
> and Python would be a piece of cake for you.pick up.
>
> Above all, I am only making suggestions. Any kind of help is greatly
> appreciated, whether it be in C or anything else, and you are welcome to do
> whatever you feel comfortable with. For me to put any kind of restrictions
> on
> helpers would only be detrimental, so keep it fun for yourself.
>
> Would you have any issues with me forwarding this to the mailing list? I
> keep
> thinking I should keep other people in the loop.
> Brent.
>
> On Tue, Nov 17, 2015 at 1:04 PM, Rusk County Manufacturing LLC
> <rc...@br... <mailto:rc...@br...>> wrote:
>
>     Hi Brent,
>
>     Traded some emails w/ Bob Eggleton about APT360.
>
>     He mentioned others would like to generate postprocessors but find
> working
>     with the native clfile format to be a barrier so I thought an XML
> format
>     might solve the problem.
>
>     Thought is to add the code to APT360 and execute it just before
> invoking the
>     user's postprocessor so as to generate a second clfile, albeit in XML
> format.
>
>     So attached an example in a ZIP file. I omitted the 1000 records
> entirely on
>     purpose, otherwise the barebones code only does a basic job of the
> 2000,
>     3000 and 5000 records, others just emit major and minor word values
> for now.
>
>     I'm emitting floating point values as decimal values here but for real
> I'd
>     prefer to emit them in hexidecimal format to preserve the full
> fidelity, but
>     would some have problems getting them to converted back ??? Easy
> enough to
>     do in 'C' but maybe not so much with something like QBasic ???
>
>     Anyway, am hoping you can find time to review and ponder and let me
> know
>     your thoughts. Thanks!
>
>     Phil
>
>
>