I toured a place recently that had all their work instructions on tablets secured to each station. The tablets were inexpensive and had login access controls and connected to the shop wi-fi. This place used work instructions created in Word with drawing attachments and then all saved as pdf's for static control (the operators could do nothing to change the pdf's.) The pdf's were revision controlled. The operators could zoom into anything as needed. Some of these work instructions had check boxes for the operator to indicate they had performed an item. These carried with them a time stamp. It was a very nice solution that worked for them.
Encrypt the heck out of your network, don't share the password with any one but Admin.'s.
Eng: I have moved us to a nearly paperless EC system.
MFG: Most of our build procedures are viewed and completed on tablets via pdf.
Learn Word well.
Learn acrobat well. This way you can eventually tie in your sign-offs to pdfs.
Concerns with PDM are simple, cost. You can assign the necessary team members a viewer or contributor (if they need to sign-off) licenses. Viewers come in packs of 5, contributors come singularly, like editors. The viewers are great for the guy who just needs to be able to see the drawings.
*** We do not store our published released pdf's in the vault (for cost of the vault) and everyone needs access to our drawings. The folder locations for these published items is locked down and collaboration with our IT ADMIN for who can read, write, print, etc.
IMO, tablets are a better option and can be cheaper than whole workstations. Tablets can be mobile so a machinist can finger his way through a drawing right next to his machine.
Hi Ian, I would recommend steering away from the single computer logged into PDM approach. I've done that and in the end, you'll outgrow it IF you get it to work.
Here are a few options I've deployed in various places I've worked:
- Use iPads with MobilePDM app. It's a little known mobile platform for accessing your PDM vault from iPhone or iPad mobilePDM :: Home
- Use Flatter Files to display vault content on touch screen monitors/all-in-one pc's on the shop floor connected via WIFI. Latest version, full search capabilities, markups, etc. and comes with a feature rich control panel for knowing who accessed what! Flatter Files is a cost effective value stream content management solution for SOLIDWORKS PDM https://www.flatterfiles.com/
- Configure PDM using the convert task to output the latest version of all drawings as PDF (without the REV in the filename and overwrite existing) to a network folder. Use all-in-one touch screen pc's connected to your network via WIFI. Train your floor staff to search the network folder for their job card/work instruction drawing by filename, and access their drawings. Change policies so the ownership of ensuring they work to the latest version is on their shoulders.
All of these work very well if the training is done correctly. PM me if you'd like more information.
Hope this helps,
Thanks for the responses everyone. The biggest problem with using anything other than the actual drawing file in the vault is making sure that the files being accessed (pdf, word, whatever) are the latest version. We are not a large enough company to dedicate an individual to that task but our catalog is large enough that keeping the "released" drawings folder clean and up to date would be a significant job by itself.
The suggestion of using the convert file task to overwrite previous versions when the new one is released is half the battle but does not address the issue of a previous version still being accessible while changes are made and/or before those changes are approved.
However, after some digging it looks like I might be able to create a new task within PDM to delete specific files within the vault. If I can make that work properly I might be able to delete associated .pdf's when a drawing is submitted for change. That would remove the previous version immediately even if the updated one isn't ready yet. My reference for this approach is here: https://forum.solidworks.com/thread/102174 but I will have to work it out a bit more as this seems to only deal with a file that is specifically sent through a state change rather than being triggered by a state change to affect a different file. As I have no experience with creating tasks, scripting within PDM or the API in general I don't have an immediate solution to that but it would appear to be possible at least. Any suggestions towards that end would be appreciated.
Before you spend a lot of time on your own solution, I think you should look at Flatter Files.
I did look at flatter files and while I haven't completely dismissed it as an option, the cloud based nature is a deal killer. I am young enough to be almost part of the internet generation but I have had enough bad experiences with cloud based software and services to justify avoiding them whenever possible.
I understand your concerns. Give Chris at Flatter Files a call and setup a trial version and see if it will work. I have several clients using it and it's powerful AND stable.
There are advantages to the paper approach as well. E.g. you get excellent contrast and very large displays that are visible even in direct sunlight. Everyone is familiar with how to use it. You can instantly generate multiple displays by putting two or more drawings on your desk.
Another less obvious advantage to paper, is that when you put out a new version, the person receiving it knows you have done so, and physically has to deal with it. This increases the odds they will review the change, rather than gloss over the revision date on the display screen. This may not matter if the person is always reading all the data from the screen to make the part. But, if the shop guy has been making the same part many times, he may already have the data in his head. So, it is more important for him to know it changed, and what changed.
A test run with your lest computer oriented worker being included may be helpful. After a short test, they may be able to comment on any issues. But, I suspect that any sneaky risks will only show themselves after months of use.
The other general complaint that I have with PDM, is that it really takes a well-trained individual to create and manage the system. In practicality, for most companies, this means your dealer helps set the system up. Then, at your company, only one person is skilled in anything but the basic check-in/check-out type of operations. And even then, you will need your dealer to do the more complex stuff, since your trained employee is not going to recall the details on a process that he used one time, a year ago.
Personally, when I do design work for my employer, I am actually completely paper-less. This was forced because I work from a remote location. The fact that this is a 5-man company makes it viable. Our sister company, that actually makes the things I draw, must use paper, since much of their work force is minimally trained, and completely computer illiterate. Obviously a company with 1000 employees is in quite a different category.
I haven't totally solved this issue but I have made some progress. Using dispatch within the admin tool I was able to create an action that is triggered whenever a file is transitioned to the "change requested" state. This new action parses drawing filename, removes the .slddrw, adds a .pdf, then searches for, and deletes that .pdf file from a non-vault location. The whole thing ended up being surprisingly simple to implement.
So at the moment I have the following tested and working in my sandbox vault:
When a drawing is approved for production, a PDF copy is generated and placed in a non-vault folder on my network. This can now be accessed by anyone with permissions to that folder (regardless of solidworks access)
When a change request is made for an approved drawing, the .pdf is deleted from the network location, thus removing access to the now unapproved drawing.
When the change request is finished and the drawing is re-released, a new .pdf is generated and placed back in the network folder.
That was big hurdle #1.
Big hurdle #2 is coming up with a good way to get the .pdf's on the monitors at the machine. I'm currently looking into options for a batch file that would address each tablet or all in one pc at the machines and trigger a file/open command to display the drawing. If I can get that to work from a remote workstation I can remove all physical access to the displays so prevent accidentally switching to a different drawing. This will require splitting the drawings into individual .pdf's for each sheet when they are generated which will require some tweaking of my delete routine but that should be relatively easy to implement.
Pictures of my dispatch action are attached if anyone would like to copy what I have done. If anyone is interested I can write up an explanation of the commands and variables to better explain what I did. The blacked out area in the first picture is the network address where the .pdf's are stored.
Ian, I don't know if this helps, but one of my VARs is Hawkridge. They often write specific code (Hawkware) to solve clients problems such as you are facing.
You should chat with them to see if they have any ideas to help. Since they know how to interact with SolidWorks, they may be able to come up with a useful solution.
If they're not your VAR, I'm sure they would like for you to transfer some seats their way if they can solve your problem.
(Note: You don't have to have only one VAR.)
Dispatch offers some customization capabilities for sure but relying on it for your value stream content management may not be the solution your company can grow into. In fact, we have several clients who outgrow Dispatch quickly based on changing process demands downstream.
My company is a SOLIDWORKS Solution Partner and we develop solutions to meet your productivity requirements. We sell powerful custom PDM add-ins and develop custom solutions to move your data throughout your value stream.
Let me know if we can help you.
To anyone that may have been following this, I apologize for not updating my progress sooner. Things have actually progressed quite far but I keep getting pulled into other projects so the final solution is not yet "final". Here's where things stand though:
The original plan of using dispatch to create pdf's upon approval turned out to be a problem because the employees who do the final drawing approval do not have solidworks on their machines, only pdm clients. As such the conversion to pdf has to take place on one of the engineering computers. To prevent a situation where a conversion is attempted but the engineering computers are not on (and to prevent sw windows from randomly opening on those machines while they are in use) the timing of the conversion has been moved to when engineering submits the drawings for approval. At that time the pdf's are created and placed in a network location that is hidden from general view. When the drawings are approved, a separate dispatch process moves the files to a visible network location. At any time if an eco is generated, the delete process searches the pdf stores for files associated with that part number and removes them so there is no chance of an out of date drawing being accessible to the shop floor.
Hurdle #2 was getting the drawings to display on a remote machine. To deal with that I have created an .hta application using html and vbscript that allows for the entering of a part number and selection of a machining cell. The application checks the pdf store to see if the required drawings exist and notifies the user visually if they do or do not. From there a single click creates a scheduled task on each remote computer associated with that cell. The task contains the full path to the pdf file as well as a command to open a pdf viewer in full screen mode with that file. The task is set to run on creation so once the commands are sent to the remote pc, the drawing is opened and displayed full screen. The application has evolved into a fairly complex and capable program with far more features that I have described but most of those are specific to my company and how we do things so they are not relevant to this discussion specifically.
Long term I hope to port the code to a proper .exe type program rather than the .hta I am using now but that's mostly for cosmetic purposes as what I have built so far works, it just doesn't quite look right in a windows environment.
So this ended up becoming a vastly larger and more complex project than I had intended BUT along the way I have gained a ton of knowledge of vbscript which has already proven useful in the development of some additional macros that we didn't NEED but are proving quite helpful now that we have them. The whole system has not been fully deployed yet due to a lack of funding for the hardware I need to install monitors on all the machines but the system has been tested extensively without no apparent issues. Time will tell if bugs appear once it is in use on the floor.
Why not just use the edrawing software to access the native Solidworks drawings from the vault. The edrawing software is free, and it can open/view native Solidworks files (no need to make "edrawing" files in order to use edrawing software to view Solidworks files). It can run on a PC, an Android device, or an Apple device. It cannot alter the original Solidworks files.
Because that requires each computer to have a pdm license along with annual maintenance. It also requires each computer to have a keyboard and mouse which I don't have room for at most of the machines. And finally, it requires someone to physically control each computer and manually select the correct drawing part number and drawing sheet.
Ignoring the first two issues and focusing on the last, each step in a job setup is a possible source of operator error. Each step is also an increase in the time it takes to get the job set up and running. This approach adds only a single step while simultaneously removing the manual selection of drawings, printing to hard copies, and distributing to the machines. The set up person needs to enter the part number, select the cell, and click one button. The software does all the verification and background tasks to get the drawings where they need to be and only reports back to the employee if there is an error somewhere. IF that happens additional action will be required but that should be a rare occurrence and would bring higher level employees into the process to ensure that everything is done correctly.
Returning to the other issues. This approach allows each machine computer to be nothing more than a display with direct operator control possible. It also eliminates the need for a pdm license on each computer, the cost of which for a single year would pay for almost all of the hardware needed to set this up.
Yes this is a much more complicated system to establish and yes there was significant time cost involved to create it but I've calculated the ROI to be about 2 years all in after which we would be saving the annual licensing costs every year going forward.