My company creates our Work Instructions using CAD software so that we can create exploded images of models with part number callouts, so our Team Members know exactly which part goes where on the assembly. These WI’s are then exported as PDF’s which we currently store in MS SharePoint and access using Views. We started looking at Tulip since it is a full fledged MES software that can incorporate not only Work Instructions, but production data analytics and reporting. SharePoint also limits the number of Views you can create to 50, and we are outgrowing that capacity rapidly, so we needed to find a more flexible platform for storing or WI documents and viewing them from the floor.
The biggest issue that I have with storing WI’s in Tulip (aside from the fact that I would prefer more of a Metadata approach instead of the semi-hierarchic structure they currently use), is that when I embed a PDF in an App, it lowers the image quality so that it appears a bit more blurry than the original document. It’s not a terribly significant difference, but it’s significant enough that some of our smaller text becomes difficult to read, which ultimately leads to mistakes on the line and rework. We never had this issue when viewing PDF’s in SharePoint, so I would think that there is some way to retain the original image quality when embedding them in an App.
Yes, we are planning on improving this in the next 6 weeks actually. We are going to increase the resolution of uploaded PDFs so they can better show text.
Can you share more about the “metadata” approach vs. semi-hierarchic structure? Curious to see if there is another change we should make, as well.
@Tulip we are starting to look at a push of “work instructions” (job sheet, drawings etc.) from CAD/CAM to Tulip dynamically. Many CAM solutions support pushing metadata which we will pull into a Tulip layout.
What CAD/CAM solution are you using today?
Will update more as we progress further on this topic.
Excited to know you guys are improving the quality for PDF’s!
In response to the “hierarchic vs metadata” structure of file storage, hierarchic is what most people are familiar with when they access their File Explorer in Windows, where you start with some network folder (C: drive, for example), and then you have a folder hierarchy in which files are stored.
Tulip seems to use a “semi-hierarchic” structure in the sense that you still have a Folder Hierarchy, but then you “pick” what files or folders are “pulled” by a Station, which gives you a bit more controlled over what your operators can see. However, if you assign them access to a folder, they can see everything in that folder (unless you individually assign each of the files in that folder). Also, if they have a lot of different documents they use, they have to search through which ones are the correct ones to use for a given Production Run, which isn’t ideal.
In a Metadata structure, you assign all of your files tags or identifiers (Such as Production Line, Part/Item Number, Station ABC, etc.) and you would then use Views/Filters assigned to each station to control what your Team Member/Operator sees. This is convenient because you can create a view tailored to a specific setup, so they only have to look at the files they need for that production run, and don’t have to sift through a whole bunch of files to find what they are looking for. You can also pick your tags so that the same file can be used at multiple Production Lines/Stations but an administrator can modify it from a single location.
If you want, you can also use a Metadata structure along with a hierarchic structure, so that files are easier to sift through for an administrator trying to find a specific file.
Hope that helps! Let me know if you have any other questions or if you want to discuss it further.
Thanks,
Carl Hirsch
Manufacturing Engineer
Therma-Stor, LLC
4201 Lien Rd
Madison, WI 53704
Cell: 608-320-8606
(Attachment File Storage Structure.pptx is missing)
We currently use Solidworks for our CAD system. Although currently, all of our assignment of metadata (the main ones we use are Part Numbers, Production Line, and Work Station) is done after importing into SharePoint. One feature that is important, is being able to assign more than one tag to a given field. For example, we have some documents like wiring diagrams that are applicable across multiple part numbers, so a document may have more than one Part Number assigned to it (which you can do in SharePoint). The same thing applies to Work Stations and Production Lines, a document may be used at more than one Work Station or Production Line, so it will have multiple Work Station and Production Line Tags/IDs.
These are great ideas, Carl! Yes, we are internally reconsidering the concept of “app permissions” which we currently have, and thinking about replacing them with “station permissions” as you suggested.
As for the ease of navigation for the operator, have you tried creating a “Routing App”? This is an app that is just dedicated to helping operators select the right app to start with.
After you start using this concept, you would only give permission on the station for the one routing app, and then operators can navigate from there based on app logic.
Sorry about the delay in responding. I typed some of this up last week but didn’t finish.
Disclaimer: I am new to Tulip so if I am wrong directionally then I hope someone will set me straight.
Regarding your use case of managing/assigning documentation to the right context - i.e. - drawing/part/station/line - I wonder if you can set up the association with tags in a Tulip Table. This table will maintain the one-many, many-many relationships and the tulip app will read the table to determine the context and serve up the right diagram/drawing. Have you considered this?
I view this like a mini-PDM functionality within Tulip.
You may need a Document Registration app in Tulip where a Doc control person registers a document with all the right context. If that is an onerous way to do it, maybe you can pull context directly from Sharepoint and load the Tulip Table. Maybe you get rid of sharepoint in the longer run?
In any case, I am wondering if using Tables can help solve this associativity issue between documents and context (part/line/station) etc.