Hello Guest it is May 10, 2024, 09:20:56 PM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - ART

1091
Ed:

  Yup, the "hard way" is the only way the CStrings will work properly. Im impressed by the amount of work you put in on the structures, I know the pain. Most of the h files are not necessary ( as you found) except for advanced plugins that use the various sturctures which
normally are untouched unless myself or Brian need access to them, but even that is rare, so Im gratefull you plugged it down to the few that are absolutely necessary for normal op's.

  Shoudl I ever do it again it will be with a Request/Modify Structure block type of definitiion. Make it much easier. Im also surprised my workaround of the pointer to functions stayed and worked properly, but thats a good thing. I just couldnt figure a cleaner method of letting the calls work both directions so the plugin coudl call Mach functiosn as well as Mach calling plugin functions.

  All in all Id say its a nice plugin package, may be some really weird plugins out over time.

Thx
Art

1092
Ed:

 Amazing job. Youve really sussed out that I did in the interface. I see the changes you made to the structures to fix up the pointers, very well done.
The only one you didnt seem to be able to figure out was

//   DoDwell() - This is sent from Mach3 to the plugin to tell it a dwell time needs to be added or removed. Engine->DwellTime shoudl be set to the new dwell
//                               and the device should also handle the new dwell ( or cancellation of dwell ) as it needs to.
//
//---------------------------------------------------------------------
 

  Other than that you figured it all properly near as I can see. Very simple setup for a base plugin, though I dont use .net myself, I can see where
this makes it much simpler for a plugin author to make a plugin that works without needing to jump all the hoops, and with VS2008 to boot.

 Colour me impressed..

Art

1093
Hi Ed:

 Thx, Ill run this and give you some feedback..

Art

1094
General Mach Discussion / Re: Problems threading on the lathe
« on: March 01, 2009, 11:24:31 PM »
Ill give this program a shot tomorrow and jam my spindle a bit to see if I can repeat this one... sounds more liek an application fault somewhere, but Im not sure yet..

Art

1095
General Mach Discussion / Re: Problems threading on the lathe
« on: March 01, 2009, 05:41:16 PM »
Hi Guys:

  Hmm, those are interesting test results. Im not sure I understand all the comments on the first one.. Im also real confused as to how this can happen but I think Im getting closer to
maybe coming up with possible reasons, if so I can test them and see.

  First, so the axis never go out of position.. thats good, it measn no loss of information at any rate, so there must be a scrambling going on somewhere.
The 3 seconds does match an internal number I use I think.. its the threading wait for stability and index.. weird that its being waited for though..

 OK, so I need to understand a bit better, you say if its slowed down to 50, then slowly worked back to 100, its OK? But not if you stop it for
more than 3 seconds? Or is it ok only if stopped for 3 seconds, but screws up otherwise? Im not sure if Im getting that right.

  So if it slows less than 50% and then speeds up is all OK? The error you get woudl be the spindle speed being sensed as zero on start of next pass calculations..

 Can anyone tell me what happens if a G32 is single stepped? And you slow it down and back up during the pass, then do the next line.. Does it taper then?

We'll track it back.. :)
Art

1096
General Mach Discussion / Re: Problems threading on the lathe
« on: March 01, 2009, 11:48:37 AM »
Hi Rich:

  Fair enough, it may explain why Im confused anyway. :)

 The only difference bwteen G1's and G32's is pretty simple. A g32 triggers a threading mode, in this mode the feed speed is modified for the spindle sync, the move is held until the
buffer has enough data in it, then started at index time.

  Now, while the moption is happening on that move, ( x,z or a mixture depending on the commanded motion ), the spindle speed is monitored. Lets say it slows by 10%, the output stream timing is then slowed by 10% to match, if the speed then goes up, the output speed of the stream goes up. It never goes faster than kernal speed.

 So the command streams are virtually identical, buffered 2 seconds of motion, the only thing that varies is the 25Khz may be slowed to 12Khz ( 50% spindle slowdown sensed.. ) or mayeb 20Khz, ( 20% slowdown of the spindle.), but in the end the only effect coded is a slowdown of the kernal speed. 

  This is all done in the driver, not the application, it monitors the spindel speed, and slows the kernal is required to lower kernal speeds. Its why Im boggled to try to find an
interaction, ( that apparently must exist) between the X and Z motion. Its as if the Z motion is not slowing, but being canceled. I suspect its only possibel if instead of slowing the kernal it actually moves the trajectoy buffer forward skipping steps output, but if that IS true, then the Z MUST go out of position.. Does it?

 We'll track this down to a "Ahh damn.." moment Im sure, but Im justa bit confused abotu where that may be. Can you speak to the Z position, does it go out of
position.. I just cant figure where the heck the extra X motion is coming from if not.. Sounds like Z is goign off, but how the heck can it come back to Z0 if thats true..

Let me know what you see though.. it all helps,

Art

1097
General Mach Discussion / Re: Problems threading on the lathe
« on: March 01, 2009, 12:28:46 AM »
Hi Guys

  there may be two effects here, first, the SS uses its own threading code, totally different from the PP, BUT there was a problem in earlier versions where the PP can do this in G76.. now the SS may have an issue if things slow too much.. dunno havent heard of it.

  So, if using PP, can you confirm its latest version, if using SS ,lt me know. I think Greg may have to look at the SS issue if there is one. But Id like to know if the PP is doing it with G32's..

Thx
Art

1098
LazyTurn / Re: LazyTurn
« on: February 28, 2009, 10:27:24 AM »
Hi All:

  Just a note on the forward progression of the program as I see it.

  The next phase is for multiple tool cuts. Each one building from the previous. The way I think its all going to work
is that the user will have only one button, "Cut" , which will replace the "rough" button. If you select a tool, and press Cut,
the system will do as it does now, BUT if no material will be removed, the user will be prompted as such and asked if he
would like a "finish pass" to be performed. So if a user presses Cut twice without changing tools, he will be promted
for a finish pass authorization. On the other hand, if material CAN be removed, ie: the tool or direction was changed, the system
will simply add just another rough pass only on the material left over from previous passes.

   This means Users will not be able to decide on their own to do a finish pass and no button will exist for one, LTurn will
only trigger a finish pass when a cut is requested with a tool that cannot remove any further material with arough pass.
 Its my hope this will firstly ensure that no tool can be hurt by improper finish passes that attempt to take away too much
material for the tool's  previous passes, and reduce the amount of decisions made by the user as well as reducing the number
 of buttons to two, one for tool selection, and one for CUT.

Optionally, A third button, FACE, will be added then to allow for the entire job to rotate 90 degrees on the screen
to allow for the other two buttons to be used identically, only in facing operations instead of profiling. That will leave only the final
optional button, BORE to be added for inside operations should I decide to go there.

  Finally,and optionally, two editing operations need to be added, one for drawing or modifying the a DXF profile, and one for drawing a custom tool shape.

    This would pretty much meet the specification I had planned from the start, an easy profiler system, with few buttons, and not a whole
lot of understanding required by the user as to tool loads and such, and as little "air" cut time as possible. If that can be accomplished I'll
feel we have managed to build something not readily available to the public as it stands, most programs being difficult to conceptualize exactly
what will happen in the cutting progression, and having many complex decisions to be made in the DXF to Gcode process, or simply too expensive
for the hobby level or intermittant lathe user. LTurn was never meant to replace CAM as Ive said many times, it is simply being engineered to
make a resonable and fairly powerful way of doing a quick Gocde operation from a simple DXF. The word LAZY is seomthing Im taking very seriously
in its design. We live in a Lazy world, and Im a lazy type guy. :)

   Im getting pretty close. The next phase will tell me just how capable I am of completion,as Im about to swap the "single pass" system to one
 of linear progression of material removed from pass to pass. If that phase works out as well as previous phases have Ill add the final finish pass
before Releaseing in Beta form and making a decision as to if I feel that facing and boring are worth moving into,though Im of the opinion
that drawing the profile to be used and saving profiles of DXF's may be a necessary thing in order to make the program fully
independant. 

 Personally Im of the opinion that profiling shouldnt be that long to full completion allowing removal of Turning from lazycam alltogether. Mayeb another 2-3 months
, who knows.. All development from that point will depend on popularity and how much the program is downloaded and used (support levels ) as Ill release a standalone
of the program to that point as a test.

 I guess from there we'll find out how many lathe people are out there that dont currently already have a favorite way of generating toolpaths. :) , and if
indeed there exists a real need for easy Gcodeing in Turn op's. Its turned out to be far far more complex than I originally though, and the work required has
been long and arduous, so we'll need some metric to tell me if my time is better spent elsewhere after that.

Thx, just a few noted on how I see the program developing, and what my rough schedule is on this one. 

Art
 

 

1099
Hi ED:

 Sounds like your almost there. :) , lets seee...


>>In the mixed mode .Net version I developed a replacement to XMLProfile that uses .Net XML. Empirically I've tested it with my Mach3 and don't see any problems but want to run a few questions by you:
1) Do you see any problems with using an indented option on the XML file? I've tried it and it seem nots to mess up Mach3. Since you appear to be using the MSXML COM object and it will accept indented I think I'll be OK. It just makes it so much easier to look at.

  Id have to see how ( or more likely when) your using it to be sure, but no, I dont think its an issue. The XML I use in Mach3 was a class object I got from somewhere, and modified a bit to work in Mach3. BUT, it has some inherent issues. For example, when used in the main timing loop, items get lost. This has somethign to do with the state of the context at time of call, but Ive never tracked it down, (Im more a master of the workaround :) ), so what I did was to temporarliy close the XML before notifying the plugin that its OK to save or get information from it. The plugin actually has its own opened XML, and MAch3 is not sharing it at all, when the plugin returns from that call, the xml is reopened by Mach3. So in your context , I suspect your fine no matter what, since Mach3 will usually not need any data in the xml, even it it doesnt understand the added entries, as long as the plugin does, no issues exists. 


>>>2) Do you see any problems with plugins written in the new development environment doing the following when it is valid for them to work with XML file:
2a) Create a DOM object

  No, again Mach3 will not try to read or use the DOM in any way, so as long as the plugin can, it shouldnt matter if it exists in the xml. Id only worry that MAch may, at some point, see the
additional entries as a corruption and skip other tags, but Ive never seen that happen, at worst it woudl simply skip over the entries till it find what its looking for.

>>2b) load the XML from the file
 
  No, again its closed whenever the Plugin has been told it can be used. So when the plugin opens it, its totally owned by the plugin for that brief period of time. :)

>>2c) interrogate and/or modify the DOM
>>2d) save the XML to the file (if needed)

 Nope, same as above, as long as the file is valid on close, it shoudl be fine when Mach reopens it.

>>3) So far it appears to work. I'm just not sure how this will interact with your handling of the XML file. I don't want to lose any of your changes and/or have you overwrite any of mine. Do you see any problems?

  I think your safe, I use the XML as a simple tagged entry list, nothing nfancy at all, I could have as easily just made it a text file and written my own parser for the data, but xml looked easier. ( I can tell by your questions your by far the expert on xml matters, :)

>>4) I've also added the option to allow plugin writers to create a simple tree structure within their section. They just have to enable it when they constuct the XMLProfile object and then they can use entry names like 'Dlg1/Int1', 'Dlg2/Txt2'. Again, empirically, it appears to not make any problems for Mach3 since the MSXML still loads and saves the file fine. Do you concur?

  Yup, totally, in fact I think its a brilliant solution, it makes the xml an extendable file that can be upgraded massively in future to contain much more usefull data , kinda like a hive of its own for Mach3, sounds to me like youve done real well.

  Ive been real deep in the code so I havent been watching close, but Brett will let me know when youve posted this, I promise Ill stop and test it out, then post anything I see that may cause some concern in future, I use VS2008 exclusively now in my own projects so it'll be an interesting test. :) ,

Thanks again for all your doing, from my simple plugin solution ( as you know I never planned for one, just kinda added it one weekend when it occured to me) , your creating a much more usefull and extendable solution.. Im impressed.

Thx
Art



1100
LazyTurn / Re: LazyTurn
« on: February 25, 2009, 04:14:36 PM »
Hi Guys:

  Its all because your trying to face operation, and you cannot really face as yet. When profileing is done, Ill look at rotating the object and profiling the face, but till then,
LazyTurn is a profiler only. :) ( Cheating aside. :) )

Art