aptos-devel Mailing List for Aptos

On Saturday 25 January 2014, Eplett, Robert wrote:
> Hi,
>
> See attached,
>
> I processed the Test.apt file through the APT360 compiler with limited
> success. See the attached *.TAP files, they are unreadable.
>
The files are intermediate files used since apt360 didn't have dynamic memory 
available on the computer it was designed for. The only significant file is the 
cl.tap file, which must be processed by another program, and is binary in 
nature. It is rather confusing, I know, and perhaps these should be named 
something more specific.

I don't have a Windows machine to test your code on, but I have tried it in 
Linux.  Lines 10 and 11 and 19 read:
     L1A= Line/Parlel, L1, Xlarge, 1+3/4
     L2A= Line/Parlel, L2, Ysmall, 1+3/4
     L4= Line/PTD, Atangl, 132+26/60

They need to read:
     L1A= Line/Parlel, L1, Xlarge, (1+3/4)
     L2A= Line/Parlel, L2, Ysmall, (1+3/4)
    L4= Line/PTD, Atangl, (132+26/60)

After the addition of parenthesis, they run fine on my machine. 	The error 
reporting is just a number that you have to look up.(The manual is quite 
thorough) That isn't very convenient, I know, and something that needs fixed.
> The Test.apt file runs and passes NC code on the
> Experimental Online APT360 Processor
> I found online, but fails on the local install
> Any assistance will be appreciated
>
> Thank you
>
>
> Robert W. Eplett
> Triumph Controls LLC
<snip>
Thanks for trying out the code and let us know if it works on Windows for you.  
 Brent (crotchet)

Phil wrote:
>Brent,
>
>Right now vision is three (resizeable, perhaps detachable) panes:
<snip>
>
>Found an editor at SourceForge called Scintilla, 
<snip>
>
>Found a free OpenGL based STL file viewer at codeproject that's pretty
> robust, albeit was written w/ VC6 and MFC (about 12 yrs old). 
>
 >
I did some stuff with STL files that you are welcome to use if you want. I have 
lately been doing a bunch of graphical stuff, but then change my mind about 
what I want to do, so I am ending up with chunks of code that I am not sure I 
am going to use or not. It might be useful, since it uses some newer C++ stuff 
like Vectors for entity containers. I have a binary STL version, too. The 
classes could be used with minor revision, if you felt like it, or just as an 
example to look at. The code is part of a opengl app using gtk+. I was a 
little disappointed  how many dependencies it had, which kept me from 
distributing it more widely. I will send you a tar ball. It should be 
relatively small. It was a re-write I started of the aptsketch code that is in 
cvs. I was learning more about scenegraphs, and decided to start over. I have 
lately put it on hold, and am porting it to Haskell. (which probably excludes 
most people from wanting to be involved with it, but oh, well). Oh, it also 
has CL file reading code, so you wouldn't have to figure out the file layout to 
the CL.tap file.

>One should be able to load multiple STL files (ex. fixturing components,
>stock(s), finished part(s), and then render the CLFILE or post output with
>colorized cut vectors (ex. RAPID moves in red, downfeeds in yellow, other
>motions in green); click on a cut vector and jump to the source and/or
> display current machine settings (FEDRAT, SPINDL, etc) as hover text. The
> reverse posting will be an additional unit of work.
>
>Going beyond simple a graphical overlay of the CLFILE / post output, seem to
>recall the opencamlib project mentions having some octree code for
> verification, that or OpenCascade?
>
You might look at openscam (http://openscam.com/) looks like pretty good code 
to me. I don't know too much about it, nor have I used it in production, but 
it seems pretty powerful.

>Be able to save and restore configuration to an XML file.
>
> From there it would develop a graphical tool to help generate the APT
> source 
<snip>
> A few predefined templates for  frequent operations (ex. facing blocks, 
making tooling holes for modular
> tooling plates, etc).
>
>Will stop there for now.
>
>Phil
What you mention is similar to things I would like to see happen. I do use the 
code I have come up with for graphical verification when I am doing 4th axis 
Apt code. I think my choice of libraries and language, however, probably 
dissuaded people from trying it, and I wasn't putting too much effort into 
making it easy for people to get and try.  If you get something going, I 
should probably put my effort into helping you out if possible. I just haven't 
been into doing all the stuff that would make a project like that more public 
and accessible, instead just doing it as a hobby exercise. 

Right now, I am learning Haskell and creating an app for visualizing, which 
uses just dxf now, but may use STL and CL in the future. What direction I will 
go in, I'm not sure. In Haskell, I'm going to be pretty lonely. I would like 
to see some good visualization for Apt in windows, since I probably will use 
Apt for 4th axis stuff for some time into the future, so I would like to help 
you out however I can.
Later, Brent.

Brent,

Right now vision is three (resizeable, perhaps detachable) panes:

* top left: APT source editor
* top right: graphics pane with options to render (a) content distilled from APT 
listing file, or (b) 'tape' file (ie. postprocessor output)
* bottom: (a) APT listing, or (b) warnings and errors summary

Found an editor at SourceForge called Scintilla, can be used as a control / 
child window that supports syntax highlighting. Something like that would fill 
the bill for the APT source editor pane and as well as the other panes with 
other lexers for the APT listing and warnings and errors summary displays. Would 
be interested to have some help to develop the lexers. Volunteers??? Anyone know 
of other / similar codebase ???

Found a free OpenGL based STL file viewer at codeproject that's pretty robust, 
albeit was written w/ VC6 and MFC (about 12 yrs old). So far have moved it to 
VS2008 and eliminated the MFC dependencies. Once its working then should be 
pretty easy to take it to make it multi-platform (prefer to stay pure OpenGL, no 
dependencies on something like GLUT).

One should be able to load multiple STL files (ex. fixturing components, 
stock(s), finished part(s), and then render the CLFILE or post output with 
colorized cut vectors (ex. RAPID moves in red, downfeeds in yellow, other 
motions in green); click on a cut vector and jump to the source and/or display 
current machine settings (FEDRAT, SPINDL, etc) as hover text. The reverse 
posting will be an additional unit of work.

Going beyond simple a graphical overlay of the CLFILE / post output, seem to 
recall the opencamlib project mentions having some octree code for verification, 
that or OpenCascade?

Be able to save and restore configuration to an XML file.

 From there it would develop a graphical tool to help generate the APT source 
(ex. pick faces / edges for a GO command then be able to lead cutter around 
part; pick points or circle centers for GOTO, etc). Perhaps keeping the APT 
source in snippets in a tree view so they can be moved around in a more logical 
manner than dumb text blobs. A few predefined templates for frequent operations 
(ex. facing blocks, making tooling holes for modular tooling plates, etc).

Will stop there for now.

Phil

On Sunday 12 January 2014, you wrote:
> Hey Brent,
>
> Haven't received any emails via Aptos-dev mailing list other than the
> announcement one you initiated 2014-Jan-02. Was curious if you heard
> anything.
>
I haven't heard anything either. I guess the interest just isn't there right 
now. I think many of them have moved on to some of the other projects like 
FreeCAD or similar. I think that Apt is a hard sell for the majority of the 
hobbyists out there. The learning curve is great, and the rewards slow. Those 
without a machining background probably don't know its storied past.

> Your email mentioned preparing an actual Windows release. Suggestions for
> something I should be working on? What were you envisioning ??? ;-)
>
Well, that's totally up to you. You've done more than enough already, so it 
would be whether or not you thought it would be a fun project.
> Any thoughts on the SYN function?
>
You might look at the source in the root directory. Sean Dolan had a Perl 
script for the SYN command (unsyn.pl). I was considering adding it to the 
"apt" script in some way, but I don't really use SYN that much, so it wasn't a 
high priority for me.
> Regarding COSMIC APT, was there something specific of interest there, ex.
> sculptured surfaces ??? FWIW, and I'm sure you've seen it (Chapter 12 in
> the manual), but APT360 has a mechanism to invoke external code at either
> the section 1 or section 2 phase:
>
> 	CALL/NAME, {SEC1 | SEC2}, a1,a2,a3,...,an ................... (1)
>
> 	where n 0 <= n <= 25
>
> or:
>
> 	CALL/NAME, {SEC1 | SEC2}, NAME1=a1,NAME2=a2,...NAMEN=an ..... (2)
>
> NAME* cannot be APT word, cannot mix and match (1) and (2).
>
By Cosmic Apt, do you mean the apt4ssx8 code? Sculptured surfaces were 
probably the most promising aspect of that code, so I am disappointed that we 
weren't able to get further.  I never looked at the CALL feature too closely.
> See there's some LEX / YACC type stuff in the repository. Status?
>
That was an attempt to write  an Apt implementation. The section II stuff is a 
bear, so I never finished it. If something like that were to be done again, I 
think the best course would to write a modern syntax front-end that compiles 
to the intermediate data representation of the apt360 section I, and send that 
to the heavily tested section II.
> Has Sean Dolan been doing any more work on VAPT? Sent him an email (Python
> 2.6 does not support TOGL, blah, blah) but did no receive a reply.
>
I lost track of Sean years ago and haven't heard from him since. I hope he is 
well, but I wouldn't count on getting any responses. Dan Falck may have more 
info.

> Hacked a bit more on my Haas mill post as I'm using APT for some 2-1/2D
> work that's painful w/ traditional CAD/CAM. Taking some baby steps on an
> APT IDE.
>
If you would like to add any code to the base, please feel free. You may, of 
course, want to start a sister project of your own, and that could work too. 
What kind of language are you planning on using, and what ideas do you have?
> Phil
PS:
I hope you don't mind me cross-posting to aptos-devel. There might be some 
people interested in what you are doing besides me.
Have fun, Brent.

Hello, Apt enthusiasts:
If you are receiving this email, it's because you've contacted me sometime in 
the past with some Apt-related communication.  I'm inviting you to join the 
Sourceforge mailing list:

https://lists.sourceforge.net/lists/listinfo/aptos-devel

Apt is still a viable tool, and progress on the code could help develop more 
interest. Recently, Phil Fuhlman(jsuber) has created a Windows port of the 
apt360 code. Check it out. An actual Windows release is probably something we 
should prepare.

If you have some ideas, or concerns, let us know.  I've also added 
administrative rights at SourceForge to the current participating developers 
in the hopes that others might have some time to make changes that I don't 
have time for. The code is a community owned resource, and I hope others might 
help in the care-taking. The offer is also open to the apt4ssx8 developers to 
add their code as a sub-project and help administer both code bases if they 
desire.
Happy coding, Brent.

hello everyone,

Been working with Brent (a/k/a crochet) off and on to get a 32-bit build of 
APT360 going for Windows and finally got it working.

The source code changes (based off of the 1.0.2 version) are checked in along 
with adding VS2008 apt360.sln, apt360.vcproj and libf2c.vcproj files and few 
other code files.

Also checked in a release build that includes mill and lathe postprocessors 
aggregated into a ZIP file. The ZIP file can be found at:

http://aptos.cvs.sourceforge.net/viewvc/aptos/apt360/apt360-1.0.2-windows-32-bit.zip?view=log

Note: there should be no extraneous DLL dependencies in the EXEs.

There is also a PDF in the same folder that attempts to document installation, 
usage and building on Windows : apt360-1.0.2-windows-32-bit-documentation.pdf

Tested on 64-bit Windows 7 so far.

Many thanks to Brent for his patience with me to get this going.

Phil(f) in WI a/k/a jsuber