[TurboStep]

... I didnt take pics of the screen but will if I try to put it back on again.
thanks

Interesting, I'll take a look today when I get a chance and try the upgrade in my environment.

If I were you I'd wait for a little while. I just tried to download v1.9.4 and found that Tormach appears to have removed it from the download page.
Step

[popspipes]

If I were you I'd wait for a little while. I just tried to download v1.9.4 and found that Tormach appears to have removed it from the download page.
Step

Hello Step,
I hope there is a reason for it, and I am not an isolated case...........

[LeeWay]

And it didn't happen on the lathe, so that narrows the corrective path down some I would think.

[adamvs]

I tried
User: tormach
Password: pcnc1100

this worked - no spaces in front of text ( that was to avoid a smiley face). Anybody been in touch with Tormach about this? Looks like they've taken v1.9.4 down.

[popspipes]

I tried
User: tormach
Password: pcnc1100

this worked - no spaces in front of text ( that was to avoid a smiley face). Anybody been in touch with Tormach about this? Looks like they've taken v1.9.4 down.

Thanks for the passwords, I dont think I will be trying it again until someone gets it to work, crawling under the machine isnt easy for me

[adamvs]

Some ubuntu questions:
1) Anybody know how to get the desktop running from the command line? I've tried startx but that didn't work.
2) Anybody tried launching PP from a desktop launched from the command line?
3) How do you re-instate 1.9.3 just using the command line?

Thanks!
Adam

[LeeWay]

You can boot up an update from a flash drive I think.
Pretty sure I did it like that at least once. That was all that was on the flash drive. That is also assuming the boot order allows that, which I think the Tormach lathe controller does.
I don't know that it would down grade though.

[snowyskiesau]

adamvs
As I'm just playing around with Pathpilot and don't have a PC with a Mesa card installed )or a Tormach mill), Pathpilot fails to start on booting and the system shuts down. To stop this, I edited the operator_login script to stop the shutdown and drop out to a gnome-panel session.
To do this, look for the line in operator_loginthat reads:

SHUTDOWN_COMMAND="$SHUTDOWN_PROG -H now"

and change it to:

SHUTDOWN_COMMAND="start_gnome_panel"

If you do this, then when to exit from Pathpilot, you'll drop into a desktop session instead of shutting the system down.

To start Pathpilot from the desktop, just type ./operator_login and the default configuration will be used. Default configuration is stored in config_file.txt

[spyderguy550]

Rebooting after the v1.9.4 update got my controller stuck like popspipes' did with no graphics and it asking for a login and password.
I figured out a fix that doesn't require reinstalling from the PathPilot DVD and losing the tool table. I hope this helps somebody out.

Disclaimer: any of the following you do at your own risk! This worked for me and might not work for you. You've been warned.

At the white-on-black 'login' prompt give it user 'operator' and password 'operator' both without quote marks.
That should leave you at a shell prompt with '$' at the end. If it doesn't then stop. The rest of this won't help.

Type in this command exactly and press Enter at the end and be sure there is a 'space' character before and after the 'rm':
sudo rm /usr/lib/X11/xorg.conf.d/15-vesa.conf

There shouldn't be any complaint or error messages and you will get another '$' prompt.

Now reboot the system with this command followed by Enter:
sudo reboot

The controller should now reboot and start PathPilot just like it used to.

[MFchief]

After find myself in the same position as popsides, and having a fairly old controller, I decided to try the procedure that spyderguy550 posted. I figured I was looking at a complete re-install anyway, so why not.

The good news is that it worked perfectly for me, after doing what was posted and rebooting, my system was up and running with v1.9.4.

Thanks to spyderguy, I really appreciated it.

Terry

[tmarks11]

hmm, looks like Tormach pulled the 1.9.4 release. I don't see it listed on the software release page:

http://www.tormach.com/pathpilot_tracking.html

[keen]

Yes it seems is it is still down.

A question for you IT experts. Is it normal to have new releases repeatedly failing so quickly?

Is it not possible to run a series of comprehensive test procedures and trials before release to find most of the issues?

When we are sent an email announcing the new release, would it not also be possible to send another to announce when it has been withdrawn?

I am nor qualified to pass judgement here, but I would like to know if this two steps forward, one step back software development process is the normal way forward.

Keen

[LeeWay]

Well, it does work great on the lathe. I would imagine it works on the mills too, but on the test bed machines that they use. I would think those are all Tormach controllers. They cannot possibly test every scenario and machine setup. The timing of it may have something to do with just taking it down as well. Right before the weekend. All they probably need is like a hot patch. The guy writing or correcting the software would be a different guy than the one that runs the website, so the weekend probably played the biggest role in the length of time it has taken to get it resolved.
Tormachs main business is not writing software. They are fixing it, so they are doing what I would expect them to do.

[shred]

A question for you IT experts. Is it normal to have new releases repeatedly failing so quickly?

It's not desired or normal but also not unusual, especially with such a variety of machines, installs and configurations. This is one reason Tormach can't support anything but their controller running their bone-stock software, it rapidly becomes impossible to test for everything, even factory configurations. If somebody fiddles with the configuration, it's on them, not Tormach to fix it.

Is it not possible to run a series of comprehensive test procedures and trials before release to find most of the issues?

Sort of, but not really. It gets expensive very quickly as the possible configurations grow geometrically. Tormach does not have the resources to do it. Microsoft has massive buildings full of people and machines testing software, automatic test-cases and all and still lets bugs out. In the '90s I developed BIOS software for a top-3 PC maker and even with 4 weeks of validation testing in a lab that did just that, you were doing well if you didn't have to release a big fix within a month of shipping. There are just too many variables to test every single combination.

The next best thing is sending it to a beta tester group which tries releases early which was done with the early builds, but even that won't catch everything. With stable builds that can be reverted to easily, it gets very easy to skip that and beta-test on the end users...

[MFchief]

As Shred talks about, the variety of machines can quickly get out of hand. You might be surprised by the number of different controllers Tormach has produced over the years. A year or so ago I wanted to buy a restore disk for my controller, and they didn't have one that matched my controller part number (about 4 years old), nor did they have one of those controllers on hand. So it could easily happen that newly produced software might have an issue with some hardware that they aren't able to test, even if they have the time and resourses to do so.
Terry

[wtopace]

I have a little different take on this - purely from being in the software industry for 10 years. If you would like a glimpse into the SW industry, I have put a few of my personal viewpoints below.

[TL;DR] Tormach will get there, this is purely a maturity issue and they are on the right path.

The simple answers are:
A question for you IT experts. Is it normal to have new releases repeatedly failing so quickly? Not for mature software companies
Is it not possible to run a series of comprehensive test procedures and trials before release to find most of the issues? Absolutely yes, full automation is preferred
When we are sent an email announcing the new release, would it not also be possible to send another to announce when it has been withdrawn? Definitely

Before anyone jumps on here me, I want to point out that Tormach is most likely not an ISO9001 certified software company. That being said, I think they have been doing a great job so far with PathPilot considering they specialize in building machine tools.

Tormach could begin by changing their software-engineering processes. Just like machining, creating software is an engineering process that goes from concept -> design -> manufacturing -> testing and iterates back through the stages indefinitely - just like a finely machined part. The only differences are that software engineers use different tools:

1. Concepts: The same for both industries - paper and pencil, coffee-stained napkins, a few friends at the bar, whatever.
2. Design: This might be Fusion360 for physical manufacturing or a series of UML models for software (both describe in excruciating detail what we are trying to build, all parts and pieces are defined and how they fit together)
3. Manufacturing: This could be the loading of tools into the tool changer or the actual machining of the product. In software, this would be implementing your classes in code from your UML diagrams. In both industries, the amount of time spent in this stage is a DIRECT reflection of how well we prepared in the previous stage.
4. Test: This is where we bust out the micrometers and measure our parts. In software, this is where unit tests, functional tests and system tests are run. This is the stage where we decide if what we built is really what we needed to build. This is where we decide if we need to go back and make changes to a single part (class in SW) or the assembly as a whole (application in SW).

Just like in manufacturing, there are tools and tricks that help out in software. It's a maturity issue more than anything else. Please feel free to correct me if my analogs below are not correct... I'm just a software guy after all =)

• Having an optical comparator greatly helps a tool builder to check his grinds - Having pre-built unit test cases greatly helps a software engineer validate that his code works the way he wants it to
• Having a Fanuc robot to load parts and remove parts greatly helps with automation - Having sets of Jenkin's scripts greatly helps to automate the software process by launching virtual computers to automatically test new code and email developers to let them know what their issues are
• Having a defect system in place to capture size and tolerance issues greatly helps the CAM engineer to update his tool paths - Having a defect system in place greatly helps the SW engineer to fix issues in the code (for example, the start script not configuring the xorg graphical interface properly, as we saw here). Without a properly implemented defect system, you're at best flailing and drowning every day, when you could be casually treading water.
• Having a solid power circuit keeps your machines running - Having a solid dev/test environment keeps your software engineers fixing bugs and creating enhancements - Whether they are computers or mills, they need to be up and running to be making parts.

This list could go on forever and in both industries it's a matter of maturity... can you get by without a Fanuc robot? Sure. Can you get by without an automated unit test environment? Sure. Can you ever match the efficiency of someone with this? Probably not.

Also keep in mind unlike the Fanuc robot - Jenkins is free and open source as are most good software engineering tools. For some reason young software companies often times want to flail early on during the immature stages, just as a new mill operator wants to guess at feeds and speeds just to see if they can get their shiny new part to hold in their hands. The drawbacks to these in both industries are very similar - poor quality output and lots of rework. Usually not a huge issue, just time and materials wasted.

Consistently good quality is expensive and takes lots of planning and is tough to execute until engineers are ingrained with processes they hate (at first). Once engineers understand that they should have their test plans and automation plans ready long before the first chip/line-of-code is ever made, they can realize the benefits of spending 80%+ time up front and cutting their actual machining/coding/rework time way down.

I'm a firm believer that with every stage in the process, cost becomes exponentially higher to make changes, why not create your test cases and automation work when your product is just lines on a coffee-stained napkin? Why wait until you have a 50lb titanium paperweight / 100k lines of Python code?

Tormach will get there, we just have to hang in there while they figure out what their process is and what tools they plan to use long-term.

[LeeWay]

I didn't think it would take long today. b version is up.

[LeeWay]

Just to let you guys know, Since the lathe is working with the original update, I will not be test driving this one.

[popspipes]

I didn't think it would take long today. b version is up.

I think I will wait for a few positive reports on this one, my knees still hurt from crawling under the machine the last time ha!!

[tmarks11]

I think I will wait for a few positive reports on this one, my knees still hurt from crawling under the machine the last time ha!!

That is one of the reasons my controller sets on the shelf in the workbench next to the Tormach. Much easier access.

In case folks are wondering what 1.9.4b brings to the table:

The original v1.9.4 release contained code that was intended to fix an issue where PathPilot would display at the incorrect screen resolution with computer monitor extension cables that were missing the EDID signal pin. Unfortunately, this fix broke the system for users with older computers. This v1.9.4b release removes this code