Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: Tweakie.CNC on January 12, 2012, 08:16:05 AM
-
Hi Guys,
After all these years as an extremely satisfied (and I mean ‘really satisfied’) user I am starting to get disillusioned with Mach3 (and the speculative, guesswork, statements that version 4 will fix all the problems really does not help).
Mach was just fine ‘yesterday’ but we, as well as our machines, all move on – more complexity, more sophistication, more function, faster operation etc etc and in my case also more laser.
It appears to me that recent revisions have catered for those that shout the loudest and have not really been for the good of all. The changes that have occurred to the way CB is treated was bit of a shock at first but the addition of “While IsMoving() … Wend” between every CB statement now seems to prevent tool breakage on the ‘auto tool zero’ routine at least.
My main gripe, at the moment, is with M11P1/M10P1and the E1P0/E1P1 commands which would switch an output coincident with axis movement in more or less exactly the same way as the Z Axis can move during any X and Y Axis movements when included on the same line of GCode. Now they just don’t work !! Why ??
Believe it or not, laser usage is going to grow in popularity and if Mach keeps moving backwards by ignoring the, perhaps unique, requirements of laser users it will get left behind in this important area of CNC. I get more than a dozen emails a week about using a laser with a CNC machine and many relating to using Mach3 with a laser and whilst I am learning fast I am still far from being an expert (perhaps I never will get there).
The LPT Parallel Port is dying in its availability so I have tried the Smooth Stepper controller and Mach (without benefit as far as laser is concerned) and am now looking toward external motion controllers which use other software (a sad day for me).
My requirements, as a laser user, are pretty basic – I just need to switch an output on when an axis moves and switch an output off when an axis stops – without any delay. Is this too much to ask ?? The E1P0/E1P1 commands that Art included (for laser use) used to do exactly this so why does it no longer work ??. Why has it been changed ??. Will it be fixed ??.
Questions that will never be resolved, or will they ??
Tweakie.
-
Hey Tweakie,
WOW, am I sorry to hear that, without doubt you are the leading light in Mach3 Laser!! Let me ask this if I can, would you be willing to do two things?
1). Send the above to Brian at the support email.
2). Re-post this to the Mach Yahoo Forum!! (Brian lurks and helps more, and faster on that forum).
He is currently traveling to the Cabin Fever show, but, Art can also kinda look into it, and I know Brian will check that board, and the his email.
Worse case scenario is this: I could make you a Plug-in that would look at the Engine commands directly, and based on it's movement and/or direction, I could
then set or unset some output for you. This would be a "Patch" solution until you get Brian or Art to resolve your issue. I am sure Brian will, since you are as I said a LEADING light in this area, and I agree Laser is a great way to go!!
Let me know if you need the patch, (even sooner if your losing money on this issue). If you do, I would need to know the Exact details of the problem, and how you need the plug to work to solve it. Call me on my phone if you choose that route.
Scott
-
It appears to me that recent revisions have catered for those that shout the loudest and have not really been for the good of all.
I agree 100%. The fact that a single person can dictate months of changes in the code for problems that only he is experiencing seems ridiculous. Especially when the changes appear to break a lot of the plugins for external motion devices.
With the way it appears now, I'll never use any 3.43 version of Mach3, and I can't confidently buy an external motion device after seeing all the things I've read.
Unfortunately, the end goal of Mach3 doesn't really appear to be a really great, stable machine control for the majority, but rather something that kinda works for everyone, but just not all that well sometimes.
And I can't understand how the current lockdown version hasn't been changed, when it has a serious M6 bug that will freeze the PC. This bug was fixed 28 versions (and 9 months) ago, but people are forced to use buggy development versions or older versions.
Shouldn't the lockdown version be the most stable, and not the other way around?
-
Hi Scott and Hi Gerry,
Thanks for your support. An additional plugin would not help as part of my problem relates to the use of the Impact / Laser plugin operation and I cannot use two plugin’s at the same time. I am not a member of the Yahoo group so cannot post there but I will send a copy to Brian if you think it would help.
It is my own fault by upgrading to later versions of Mach as they were released and I have tried going back to earlier versions but then other things that I have since added don’t work correctly (C++ stuff for example) and it has all become quite a pain.
I just want E1P0/E1P1 back working even if I am the only person in the world (at the moment) that wants to use it ;D ;D
Tweakie.
-
Tweakie - I have to declare an interest and confess to having shouted loud ONCE. I've been working very hard recently to release a new DTHC for Mach but there are issues with "reverse run" that I dearly wanted fixing. I tried to get help here but in the end took advice and took it direct to Brian on Yahoo. I have to say he was very good and sent me a fixed version to test which proved to have solved the issue. In fact I just finished testing it today. How that eventually gets merged into a release I don't know. The bottom line is if you get in touch with Brian I'm sure he'll do his best to get YOU a working version to test. Like I say - how this gets blended into a stable release I don't know. I'm afraid the software development cycle of Mach is a bit of a mystery to me. In the meantime I understand the problem you're having - we discussed it many moons ago - I'd be happy to stick it on the yahoo group for you right now if you like - let me know.
Ian
-
I'd be happy to stick it on the yahoo group for you right now if you like - let me know.
Most grateful if you would Ian I haven't even found the support email for Brian as yet. ;D
Tweakie.
-
pm waiting for you
-
My requirements, as a laser user, are pretty basic – I just need to switch an output on when an axis moves and switch an output off when an axis stops – without any delay. Is this too much to ask ??
At the risk of displaying my ignorance here, would not a simple brain be capable of doing this?
-
And . . just to 'throw another shrimp on the barbie', I am working on a motor controller that talks to MACH, but is essentially autonomous.
Based on that (rather limited) experience, it *seems* to me that it would be possible to have a PLC 'snoop' the actual step streams and turn on the laser directly with an infinitesimally small delay. IN this way, you would have immunity from anything the 'powers that be' break now or in the future and also such a method would work with any CNC software and for that matter probably with any external motion control as well.
. . just thinking out loud.
-
Tweakie,
I'd be very happy to forward your message direct to Brian if you like.
I share your pain. I just completed switching over to a KFlop, using their KMotionCNC application instead of Mach3, while I finish writing my CNC controller app (which is currently about 70% done). There are many reasons I would've much preferred to get my issues with Mach3/SS sorted out, but it was just taking too long.
I feel bad, because Brian and Greg have provided great support and I really enjoyed working with them both, but, end of the day, I have to be able to get my work done, and I simply could not do it with Mach3. I'm sure Brian will get it worked out eventually.
-
As a Long time user I share your pain. But for the most part I have merged away from Mach3 for the same reasons. Good lord know I have preached about it BUT I am not the squeaky wheel. Many thng s over the years have just stopped working as they did. The CB side has gotten tottally undependable to the AVERAGE user wanting to do macros for MACHINING.
THere was a "short" discussion on the Yahoo site about Plugin programming distractions dealing with Mach3 and the countless hours they stole from the Mach3 debugging over the years
I really wonder where MACH3 would be today if all of those plugin distractions had not come along and all those hours had been to debug Mach3.
HUM??, (;-) TP
-
Thanks Tweakie,
Well said. You are not "the only person in the world (at the moment) that wants to use [ E1P0/E1P1]". I am having the same problem with my little
laser diode machine, and I, too, experienced the delay in trying to trigger the diode with axis movement. My work around of using the C axis
direction pin is a less than satisfactory compromise, and forces me to use a custom gcode post processor and mods to my own software program.
Perhaps your post will lead to a proper fix.
Thanks again,
John Champlain
www.picengrave.com
-
Thanks Guys, you are all very kind.
Tweakie.
-
Hey Tweakie,
You should be a lathe user ........ ;) :D >:D
RICH
-
Tweakie:
I hadnt heard about E1P1 being nonfunctional. Brians at a show, but Ill ask him when he returns what the probalem might be. I think we can probably get that fixed up for you, I put it in orriginally for Laser, but Ive found it has other uses as well so Id hate to see it go away as well, but in this case, if it did go away , Im thinking it was nonintentional.
Its basically a driver extra command to do soemthign during a particular step pulse. Liek you said, impact as well as Laser needs it so I dont think it is purposelfully gone.
In fact, it may be something I did to the driver on some iteration or another and was not reported to me, but I will look into it, and see about getting it fixed. I know where its generated and I cant see any macro changes having broke it, but Ill check when Brian gets back ..
Thx
Art
-
Tweakie, are you using the SS? I was under the impression the latest plugin for the SS had the M10/11 in it. Does it not work
Hood
-
It appears to me that recent revisions have catered for those that shout the loudest.............
Looks like they heard you. ;)
-
Actually, :), the moderators here often ask me to comment when they see someone with a legitimate problem when Brian isnt available.
Cant speak for him, but in problems like this one Brians pretty good about finding an error.
:)
Art
-
Tweakie:
While I think about it... did this problem affect your impact plugin? That seems to have the same functionallity, but in reality uses a totally different methodology? Id like to know if that still works..
Art
-
Hi Ian,
I will get back to you later today in a PM.
Hi Rich,
Wish I was a lathe user, sometimes. ;D
Hi Art,
Thanks for the response. As you say, I am sure it was non-intentional but the The E1P1 / E1P0 seems to be a buffer type of problem as it will work for a small number of instances (6 or so) then it will freeze for a while then work then freeze and so on. When it does work it is just such an excellent command for fast switching it would wonderful to get it back again.
The existing Impact/Laser plugin which uses the digital trigger output is not affected by this issue.
Hi Hood,
I must admit to having not tried the very latest SS version software. Thank you for the information.
The Mach derived M10 / M11 suffers similar problems to the E1P1 / E1P0 and will freeze during a long repetitive sequence but the new SS derived commands may behave very differently.
Unfortunately, nothing is ever simple as my SS installation is currently on a milling machine and is not plug for plug compatible with the laser but when I can I will transfer it and see.
Hi Gerry,
You are quite right and it is a bit ironic really because the response has really exceeded my expectations.
Thanks to you all for your assistance,
Tweakie.
-
Hi Rich,
Wish I was a lathe user, sometimes. ;D
Believe me you do not ;)
Brian always tells me to nag to get him to work on Turn but so far I have resisted the urge as I want him to spend time on Rev4 and fixing up Turn in Rev3 will just distract him from doing so. Now that the new guy has started maybe I will ;)
Will be sending you a PM in a few mins.
Hood
-
Tweakie:
Thx, that narrows it down , also makes it applicaion, not driver so at least I know I didnt make that bug on my end
over time. :) . Ill discuss it with Brian when he returns and we'll see whats up.
Have fun,
Art
-
Thanks Art, your assistance is much appreciated.
Tweakie.
-
Hello guys,
I would like to say that I am sorry that I am not able to make it so the software can be everything to everyone as much as I would like it to be. The trouble that we have is that Mach3 (originally Mach1) was designed to be a simple CNC app (for routers and mills) that had little in the way of customization. Then Mach3 grew into a CNC App with some customization with scripts and so on.. GREAT! That makes it so you can do anything! (also you can screw up anything). Okay Now we have added Plugins so you can have external devices and add IO. What a joy! we can add and have about anything we like on the machine but this came at a very big price. The base code in Mach3 is not ideal for what we have today and working with it is like trying to add on to a house of cards. ANY card out of place it will all fall. You have no idea the pain that I go through to work on the code in Mach3 and how much I fight to NOT change it.. I have been trying to add features in a way that is not going to mess up the basic application. But with everything being global pointers I can't stop anything from changing data in Mach3. So there is the sob story.. what are we doing about!
I am working on Mach3 all the time looking for issues. I spent months working on Rays issue and found some of them (both of us to blame). At the end of the day he will end up with his own little interface for the KFlop and I am happy that he is happy. But I lost months of dev time and I wouldn't change what I did. The fact that he didn't get what he wanted was not a lack of effort. I offered more then one time to fly him out with his PC work work at the office here and to get it working as he would like. I also offered to fly out to work on his machine. I don't know what more I can do other then to build up machine and send it to him. If that is not good support then I just don't know what to do and I give up. I work with so many people to fix there issues (90% is special interests) that I do very little dev work. to fix this we have brought on a full time programmer and support guy. This programmer works everyday on Mach4 and he is a programmer of over 25 years. He and I talk everyday making the API and then he makes the code to match the API. This is what needed to be done to make Mach4 be the most stable app that it can be. We have also made a decision that we are ripping out ALL the custom code for users with "special functions". THC, Foam cutting, Tangential, Laser etc.. are getting ripped out of the software. We spend more time trying to get everything working for everyone and we can't do this anymore. Now having said that we are still going to have THC, Foam cutting, Tangential, Laser etc.. but it will be moved off into modules that you can add. This is making the core code to Mach4 much more fun to work on (it is simple). Also we are not going to have global pointers anymore (this is because we are making it so we can change the code and it will not effect the plugins) Plugins will no loger be able to play with Vars in Mach4. They will have to go through an API call so we can be sure that we are not getting any data overwrites. Also the P POrt is not going to be part of Mach4. the P Port will be a plugin that you can get or not.. The future is not going to be 25pins LOL. I know this is not going to fix the issues that you have now but I would like you to see just a small glimpse of what I have to do everyday...
So what is this rant... Yes there are errors and I work everyday trying to fix them when I know about them. And we know what the base issue requires a complete rewrite that I can't do because I am supporting Mach3. To get you what you need in the future we have a programmer working full time and to get the current code doing what you need I am working full time. Contact me if you have an issue and I will work with you..
This may be more then you wanted to know but it is what it is.
Thanks
Brian
-
Hi Brian,
I have sent you a PM.
Tweakie.
-
The trouble that we have is that Mach3 (originally Mach1) was designed to be a simple CNC app (for routers and mills) ...
The base code in Mach3 is not ideal for what we have today and working with it is like trying to add on to a house of cards. ANY card out of place it will all fall. You have no idea the pain that I go through to work on the code in Mach3 and how much I fight to NOT change it..
Actually, some of us do have an idea of the pain.
And yes, the complete rewrite of the kernal is the only solution. Some of us KNOW this. (Painfully.)
So, two things: this sort of communication is vital, and some faint idea of the schedule would be very nice. Are we talking a week (hoho), a month (hoho) a year, or what? NO promises, just a hint to help your customers with their planning.
Cheers
-
Brian, please make the Tempest trajectory planner an option right from the start. Even unfinished, as it is right now, it can be a big improvement over Mach3's current CV mode.
-
Just to backup what Brian said, his support has been truly outstanding, and not just for me, but for many others as well. He put a huge amount of time and effort into working on the issues I raised, and quite a few were fixed along the way. But, for the reasons he described, fixing one bug sometimes uncovered, or created, a different one. That is why it is so important to get Mach4 finished - Mach3 will NEVER be as stable as it needs to be, because of its legacy. This is the way of software - it always needs a major re-write after a certain period of time, and Mach3s time came some time ago. It was ALWAYS a real pleasure working with Brian, and Greg, and I will really miss that. I have no doubt when Mach4 finally arrives, it will be a HUGE improvement over Mach3! And when it's ready, I'll be eager to give it a test-drive!
Regards,
Ray L.
-
Just want to ad my (usually controversial) two cents worth to this topic. I don't have a dog in this fight and I am not a Mach guru by any means, I do have a lot of experience in machine design, manufacturing processes and programming. I have recently taken my first foray into some basic 'bare metal' programming of Mach using Modbus (both serial and TCP), brains and screen mods. I have a need that Mach does not fulfil, so as I have done previously, I extract the data from Mach and create my own solution.
My observation is this; Mach is extensible and open, yet when someone has a specialty application, instead of using that open architecture to tap into the data that is available and using it to create their own application, they lay their special needs on the shoulders of the developer.
While I have to say that I am also distressed by the general instability of Mach, I can see now where some of it comes from; namely catering to the 'lobbyist's' instead of bulletproofing the existing code for those who dare to try use it in a production environment, or those who are foolish enough to invest a lot of time in developing around it, and let the 'special needs' group do their own customizing.
As an example of how pervasive the 'save us' attitude is, I made two suggestions for solutions to the issues raised by the OP. Not a single comment on those ideas. Not even to blast me and say they suck and won't work? Nothing. No other ideas were put forward, yet the complaining continued unabated that Mach was not solving every problem.
Certainly there are going to be exceptions to this rule, but so long as the data is retrievable from withing Mach, people should use that capability to create their own special applications and not pressure the developer to refocus resources on the few to the detriment of the many.
-
My observation is this; Mach is extensible and open, yet when someone has a specialty application, instead of using that open architecture to tap into the data that is available and using it to create their own application, they lay their special needs on the shoulders of the developer.
While I have to say that I am also distressed by the general instability of Mach, I can see now where some of it comes from; namely catering to the 'lobbyist's' instead of bulletproofing the existing code for those who dare to try use it in a production environment,
Harsh words, and yet some truth maybe.
However, more debugging of the core and less 'feature extension' might prove commercially profitable.
Cheers
-
All good intersesting stuff but let's not forget the distinction between asking for new features and asking for broken features to be fixed. Also let's not forget that it never hurts to ask - but that doesn't mean it's going to or has to happen. Let's not play the blame game.
Ian
-
Hello Guys,
I would love to post more about what we have done in Mach4 but I don't feel that the time is right. We have a few more things that we need to do that are very open ended. As soon as they are done it will allow use to get a very good idea on the date for release or even for me to tell you what the feature set is. I have an API doc for mach4 but it is a little over the top for a regular user ( talks about how to use C# as a GIU and all that junk). the fact is that we are moving at a warp speed on this project and the quality is amazing. We also have taken what I have learned from Mach3 and trying to make it as safe as we can for you the user to make your own customization. The true goal is simple.. Make a simple app that can have items added to make it be what you would like it to be. Having said that there was a question about if we could add Tempest.. Yup.. We can! Can I add a new scripting engine.. YUP! Can you have a new Gcode interpreter? YES! Can we add Canopen YES! Mach4 is built to be more flexible then mach3 ever thought about being.. We may make it so you can run more then one machine at the same time . So as you can see I will post but let us get past the rest of the road blocks. The road block that we just got past was how to pass OpenGL to C# so an OEM could make a new GUI and not know how to program OpenGL.. And yes that could also be changed out :)
Mach3.. Ron and Steve talked to me at the show and they have the idea that we should post the bugs that we are working on.. I don't test anymore I have Andrew doing that, so the idea is that I will have Andrew make a webpage where he can post what we will be working on so you can see what the heck it is that we would like to do for the next rev (Bug fixes). Having said that I have no idea how long that will take but that is the plan..
Thanks
Brian
-
I have made a Forum topic for the time being of the "Bug List"
http://www.machsupport.com/forum/index.php/topic,20609.msg143156.html#msg143156 (http://www.machsupport.com/forum/index.php/topic,20609.msg143156.html#msg143156)
Thanks
Andrew
-
Mach3.. Ron and Steve talked to me at the show and they have the idea that we should post the bugs that we are working on.. . . . make a webpage where he can post what we will be working on so you can see what the heck it is that we would like to do for the next rev (Bug fixes).
An indispensable tool available in many development environments. My number one frustration with Mach has been spending hours fighting with an issue only to find that it is a known bug. Until my current motor controller project, where I had no choice, I have avoided building anything around Mach for that reason. With a known bug list, which is at least as important as any other debugging tool, I would go to that resource at the first sign of irregular behavior to see if debugging the issue will be (temporarily) futile or more important, if there is there a current work around . . which should be part of a known bug listing, incidentally.
Other than staying focused and prioritizing fixes over features . . . . and perhaps further organizing the still splintered and incomplete documentation . .(hint, hint) . . . this bug list is probably the very best tool you can provide for developers who want to work with Mach. It demonstrates that ArtSoft is acting to respect a developers time.
Kudos . . .
-
Tweakie:
Quite a discussion here since your question on E0P1 etc.. :)
Andrew tells me that function was not removed, it shoudl still work. Can you describe exactly what its doing?
Does it just stop.. or does it stop working after so many lines??
Art
-
Hello guys I think I see the error.. in the Fix I added for the SS it made an error for the E0P1 type stuff.. but the good news is that the M10P1 and M00P1 should work fine.. I have sent out a rev for testing so we will see what we get :)
-
Thanks Brian, thats was the original request on this thread, I think it was misunderstood as a gripe about somethign not being available, but I knew the code was tied to
output so it shoudl have worked. Its mainly for lasers or impact printers, but the impact printing has been a busy thread and Ive been impressed with Tweakies results in that as well as the interest others have in impact printing, so thats a functionallity that should stay for extenral device makers who wish to offer it. Any printer port plugin will have a hook for it.
Preciate the clarification.
Art
-
I think from looking back at trouble notes a problem with the function was also a DELAY that had somehow crept in causing the laser problems most had to move away from the function and go to the Dir pin method.
Just a thought, (;-) TP
-
Hi Brian and Art,
I have sent emails with attachments of the test results etc.
Tweakie.
-
Hi Guys,
Well, as Art has said, this topic certainly stirred up some discussion.
Brian has been just brilliant and has now restored these, undocumented, commands M10P1/M11P1 and E1P0/E1P1 and in the latest version he sent me to test they work just perfectly. There is now no noticeable delay with these commands as can be seen from the picture of the test sample I used.
A big thanks to Artsoft, Brian and the Team who responded so rapidly to restoring these commands which (as others have said) only benefit a very small proportion of the total, worldwide, Mach users. These changes will be incorporated into version R3.043.056 as and when.
Obviously I will no longer be looking at alternatives for my machine control but this has perhaps demonstrated, at least to me, just how fickle we (I) can be. ;D
Tweakie.
-
Tweakie and the rest of you fine gentlemen.
I have no complaints to make. I am extreemly happy with Mach3. I use version 22 (the stable version?) and look forward to the release of the next "stable" version. I am very pleased that Brian and ART have both posted here. Its great to see the men in the know and doing the stuff reading gripes etc and then posting replies.
I read with great interest Brians Mach 4 posting. I do have one question, its quite possibly not the place to post here but here goes anyway. I use a G100. I know its old, superceded and not supported but I love it. Its reliable, does the job and has loads of input and outputs available. I do use these. Its also driven via network! All positives. I know its reported that the FRO wont work on the G100 but I made a macropump work around for this and mine works. To a fashion. lol. OK< the question is this, will Mach 4 still work via my G100? I would change to the SS but I prefere not to.
Regards and keep up the good work. MOST appreciated.
Mike.
-
I don't know if it will work with the G100... If Gecko is still going to sell them I would think about it but I am not sure if they do or not :(
Mach4.. soon I hope to tell you all a bit more about what is going on with it.. I want to tell you what is done next, not what we are going to do ;)
Thanks
Brian
-
Brian
Thankyou for your very prompt reply.
I do not think that Gecko sell them. They dont support them and they have dissapeared from their website. I got mine from them around 5 years ago. As I said, I am preperared to go the SS route. I dont need the network version, the USB version would work just as well. I just need more inputs / outputs than the paralel ports offer.
Regards.
Mike
-
As I said, I am preperared to go the SS route. I dont need the network version, the USB version would work just as well. I just need more inputs / outputs than the paralel ports offer.
Regards.
Mike
As you are needing the I/O the ESS may be a better choice. It has 3 full parallel ports worth of I/O where the USB SS only has 2 and 6 inputs on port 3.
Hood
-
Hi Hood,
I dont know, I havent botherd looking for alternatives. I am very happy with the G100 but when Mach4 comes out I will migrate even though it looks that I will have to change the motion controller. When that happens I will take advice.
Sorry, that sounded wrong but you know what I mean.
Regards.
Mike.
-
No probs :)
Hood
-
as can be seen from the picture of the test sample I used.
Having tried to make such dials with a carbide engraving tip, I can only drool at this example. Can one commission?
Cheers
-
Lasers do such NICE work, dont they? lol
Art
-
It is quite refreshing to see Mach3 receive a standing ovation in conclusion to a topic titled "Getting Disillusioned with Mach3".
Where there's a will, there's a way.
Great work Tweakie, thanks ART and Brian.
Russ
-
these problems need fix fast as win xp 32 bit will be gone very soon as in next 12 month a stable 64 bit version needs to be done now for lazer,router,mill,lave,plasma ect, as tec gets cheaper like lazers mach3 needs to keep up please keep up. concerend mach3 user
-
Sooo M11 and M10 will still not work with the SS. I'm looking to turn on and off different outputs without any delays..
-
as win xp 32 bit will be gone very soon as in next 12 month
It was meant to be gone years ago. We were all meant to migrate immediately to Vista, then W7, and now W8. Kowtowing vigorously to the alter and handing over our wallets.
Reality is however that a LOT of major commercial users have told their hardware suppliers that future hardware purchases will be conditional on them coming with WXP SP3. Not W7 in WXP mode, but actual real WXP. They simply do not want to go through all the hassles of retraining and re-solving HW and SW problems with a new OS. They have been burnt once too often already, they have heard of all the hassles with Vista and W7, and they just don't want to know!
And those customers have the whip hand now because current HW/SW combos are quite powerful enough to last for another 5 years or more, and if they stop buying for a year or two the HW vendors are going to feel incredible pain.
I imagine (HOPE) once Mach V4 comes out it will be much more modular and able to be recompiled for other platforms. Who knows - maybe it could be recompiled to run on ... Linux! With REAL real-time support (plus Citrix or ...)! (drool!)
Cheers
-
these problems need fix fast as win xp 32 bit will be gone very soon as in next 12 month a stable 64 bit version needs to be done now
It's more likely that parallel port support will go away then be ported to a 64bit OS. Plenty of people are using Mach3 right now on Windows 7 x64 with the Smoothstepper and KFlop, and probably other devices as well. It appears that the future is external hardware, and if it is, then it's already here. :)
-
It's more likely that parallel port support will go away then be ported to a 64bit OS. Plenty of people are using Mach3 right now on Windows 7 x64 with the Smoothstepper and KFlop, and probably other devices as well. It appears that the future is external hardware, and if it is, then it's already here. :)
Genuine full-blown parallel port support went away quite some time ago in fact. :-) :-)
Anyhow, given the realities of the NON-realtime nature of Windows-X, external hardware support is now a de-facto requirement for anything serious. Even hobby-serious. But that is OK imho. The PC does the file handling and grunt calculation, which it is very good at. The external HW does the real-time data streaming.
To be honest, when I first got into CNC I did not realise just how time-critical the direct drive of a CNC is. I should have, given my decades of work in real-time systems, but I didn't. Those external boxes such as the ESS are pivotal to good performance. Mach V4 could lose the PP without a problem (as long as they coordinate with Warp9 etc before the release.)
</soapbox>
Cheers
-
The PP driver will be in the form of a plugin in rev4, whether that means it will work on a 64bit OS or not I dont know.
Hood
-
The PP driver will be in the form of a plugin in rev4, whether that means it will work on a 64bit OS or not I dont know.
Fair enough - good approach.
Does anyone know whether there are 64-bit-compatible PP hardware units out there? I mean PP units which can work with Mach. Given that most existing adapters for current 32-bit systems can't drive Mach3, one wonders whether it is even worth while writing a PP driver.
Cheers
-
The Mach3 driver doesn't work on a 64bit OS. Without that driver, no parallel ports will work with Mach3.
-
:)
I hope to run experiments within a couple months to see whats possisble in a new driver. Win8 will not run the PP driver even in 32 bit mode, I tried it already,
so any future for the PP requires a new driver. If I have to do that, I may try a 64 bit version as well.
( Just saying.. lol )
Art