Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 45

Thread: Designer S/W Manual

  1. #21
    Join Date
    Feb 2014
    Location
    Temecula, CA
    Posts
    71

    Default

    Connie, please do not take my comments personally, from what little I have seen, you are a hard worker who spends much more than reasonable time dedicated to the CW program. I see your threads all over the forum, even on weekends. In addition you have a full time job.

    Neither do I want to be thought of as a complaining flake on this forum, so I offer some background. My degrees are a major in EE and a minor in applied math. I spent 25 years with a company that provided consultants to the U.S. Air Forces Space Systems Division space programs. About the time you were born I was writing guidance equations that placed the Mercury and Gemini astronauts into precision earth orbits. If we had handled our S/W development the way LHR does theirs, we might never have gotten the astronauts into orbit or worse yet lost some of them and never known why. Yes, I know this is not a life or death situation BUT doesn't LHR have a fiduciary responsibility to its customers? Please entertain my observations:
    1. The "NASA engineers" that developed the CW system were H/W engineers and knew little about professional S/W development. There is a users manual for the CW A and B hardware and a users manual for the C hardware. There are also numerous H/W use videos.
    2. There is no usable/modifiable S/W documentation/manual for the designer S/W either version 1.--- or 2.---.
    3. The whole of the 2.--- S/W knowledge/use is given in a 13:26 minute video.
    4. LHR does not maintain a S/W library, strictly control the S/W versions, or develop the CW S/W in a generally accepted professional manner.
    5. Someone at LHR permitted the LHR employee that generated the Designer S/W manual for version 1.--- S/W to leave the company without assuring that the designer S/W and documentation were secure in a controlled environment, or library.
    6. Connie, you state "We write the S?W in house". I assume that means all the S/W. Are there any controls and/or complete documentation on any of the S/W?

    I do not intend criticism of LHR or it's hardworking employees, but to point out areas where small changes could make vast improvements in a product that we all respect and enjoy.

  2. #22
    RMarkey's Avatar
    RMarkey is offline Firmware Lord, Web Guru, IT King, Raccoon Catcher, Cable-repairer, Bucket Dumper, Undisputed Thumbs-Down Champion
    Join Date
    Aug 2007
    Posts
    923

    Default

    I think one reason we pass the buck on our docs is that at one point, we spent hundreds of hours creating it only to find out nobody was reading it. We would get the same questions called into our tech support lines over and over again -- all of which was answered in the documentation.

    So the forum was started, and other users could help answer repetitive questions, in a friendlier language. The "tips and tricks" was created, as real-world examples were much better than technical explanations. AskBud's videos led to our creating more instructional videos.

    Hopefully a picture is worth a thousand words.

  3. Default

    I still think some documentation is needed. I want to note that tips and tricks has also not been updated or added to in some time. I understand that people will often ask questions that are located in the documentation just as people will often come on the forum and ask questions that if they did a simple search they would find the question has been asked and answered many times. That does not relive a company of the responsibility to put out basic information on the use of the products it sells. You can not assume the level of competence of your purchaser especially when the product is sold as a hobby machine for the novice.

  4. #24

    Default

    I tend to learn the software by using the software and when stuck look at the help files. I talked Chris a long time ago and he said documentation can take a PHD to compile.

    Michel Taylor has done a excellent job on the tips and tricks with the exception of a few things I tend do different like board layout. The best way to learn is to visualize what you what to make then try it over and over until your happy, this also means using the machine and testing over and over until your on top of the grade.

  5. #25
    Join Date
    Feb 2014
    Location
    Temecula, CA
    Posts
    71

    Default

    Mr. Metallus, of course your comments are true. The only time most of us read documentation is when we get stuck and no one is there to provide answers. Documentation is a dirty word to a S/W developer to be shunned at all costs. Been there done it myself. That is when the management must stand firm.

    However your argument does get rather thin when one realizes that you have documented user manuals for the A & B machines and another documented user manual for the C machine as well as providing action videos. I bet that as many people were/are not reading the H/W manuals as would not be reading the S/W manuals if they existed and that there as many calls and wasted hours explaining the H/W workings as there are explaining the S/W workings. HOWEVER that fact did not stop you from documenting and providing user manuals for the H/W.

  6. #26
    Join Date
    Aug 2008
    Location
    The Great Texas Gulf Coast
    Posts
    5,314

    Default

    Changing the medium of the documentation from written to visual does not mean a company has relieved themselves from their responsibility. Personally, I don't feel there is a lack of documentation. I almost think the amount is overwhelming.

    A manual might be fine for defining features, but it does not show you how to combine them to create a project, as many are. That is why there are Step-by-Step tutorials that take you through a project build. I do, also, agree with LG. Start playing with the software. Click on this button or that button to see what it does. It doesn't mean you have to carve it.

    Anyone wanting to contribute a new Tips & Tricks (written or video format), like others have done, are welcomed to send them. I may have a template somewhere or at least the logos for you to use.

    FYI - I have added descriptions to several of ASKBUD's videos. Still working on it, as he did a lot of them.

    One of my customer service techs is now working on some written documentation for Designer 2.00+. It will not be a comprehensive look, but a general description of the new features.
    CarveWright CX Packaged System - starting at $2000
    CarversClub 1 Year Subscription - $150.00/year
    Adv. Support w/out CC membership - $25.00/issue
    CarveWright Community Forum - PRICELESS!

  7. #27

    Default

    However your argument does get rather thin when one realizes that you have documented user manuals for the A & B machines and another documented user manual for the C machine as well as providing action videos.
    Not understanding this, the machines are overall same.

    I bet that as many people were/are not reading the H/W manuals as would not be reading the S/W manuals if they existed
    Again I not sure what your saying the software manuals are available in a few forms. have you updated to 2.005? do you have all the plugins? Conform, STL,DXF?

    I think pointing out hiccups is importing but I not getting the overall issue you having especially with someone with your background in Computer science.
    Last edited by liquidguitars; 03-31-2014 at 01:21 PM.

  8. #28
    Join Date
    Feb 2014
    Location
    Temecula, CA
    Posts
    71

    Default

    WOW! that certainly was not our approach when putting men in space. I know this is not the same, but your approach can be a huge wast of my time and resources. In fact it is a huge waste of time and resources of all those that use the CW machine.

    As far as Chris's comment is concerned, are PhD's writing the H/W documentation? If so then they are on staff and can be made available to document a S/W user manual. When developing S/W the programer has many problems to solve and in general only he/she knows the path that was taken. After the fact if the path is not documented the programer can forget, leave the company(as in this case), be transferred, etc. and the chosen solution lost until; an unsuspecting user runs into it, ruins the project and has to start over.

  9. #29
    Join Date
    Feb 2014
    Location
    Temecula, CA
    Posts
    71

    Default

    "One of my customer service techs is now working on some written documentation for Designer 2.00+. It will not be a comprehensive look, but a general description of the new features".

    Connie, that makes me very happy! I believe it is a step in the right direction. Please continue in this path.

  10. #30
    RMarkey's Avatar
    RMarkey is offline Firmware Lord, Web Guru, IT King, Raccoon Catcher, Cable-repairer, Bucket Dumper, Undisputed Thumbs-Down Champion
    Join Date
    Aug 2007
    Posts
    923

    Default

    Documentation is a dirty word to a S/W developer to be shunned at all costs
    I've quit jobs because of lack of documentation. Most of mine is internal. I still release individual docs on specific functionality. I choose to take the time to do it.

    They are scattered throughout the website. Some are hardware manuals, some tutorials, calibration, troubleshooting, error messages, etc. I only document the firmware, although I manage about 15 different projects not seen here in the forum.

Page 3 of 5 FirstFirst 12345 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •