I tested with 2015 SP4, your settings worked for me. There were some weird set card variable issues with Dispatch in 2014. (Still some in 2015 too ) What are you running?
Jeff, thank you for your help. I was running 2015 SP3, then updated to SP4 just for this problem.
After your post, I had a suspicion that a variable called "Version" might cause some glitches as it is exactly the same as the system variable for actual version of the file. Therefore, I created a new variable called "VersionT" (for temporary value). I have tested it further, and I have noticed, that actually the value is assigned to this variable as it should be, and it is displayed in the data card. However, this variable is not written to the custom property of the file.
Interesting part is, that it sometimes is working: I tried to increment the value of 10 (current version of file plus ten) - it started working ! Both data card and the custom property. Changed it back to "plus one" - what do you know - it is not writing custom property anymore. Changed it back to ten - still nothing ... I really don't get it - tried restarting the workstation - doesn't help. Looks like a bug ...
So, probably dispatch has nothing to do with it. This is the variable itself:
Is there anything else I can do to make this variable be written to custom properties?
I set this up for a customer but got there slightly different. Instead of doing the add operation at the “Set Variable” command line I do it in the dispatch variables. I’m set for doing this before checkout so it might work a little different but…
I did have to add the Model_Version variable to the data card.
Note: this is on EPDM 2014 SP5.0
Tom, thank you for your input. This is another way of doing the same thing, just split into two steps.
I think I found the problem. This only makes me think how much do I have to learn about EPDM...
So: the variable is always assigned correctly: I check it through the data card, and it is always there. If I manually go in to the explorer, into the vault, select the file, then "Modify>Update>File attributes from database", then the custom properties are written in to the file. They are there when I open the file and check the custom properties.
However, if I don't do it by hand (updating these attributes), then custom properties inside the file are not updated (I think they got updated a few times automatically, but I am not sure anymore ...).
I was certain all the time, that exchange between EPDM variables and file's custom properties are instant and automatic, if only "Block" and "Attribute" are set for that file type and block name is set to "CustomProperty" inside the settings of the variable. It looks like I was wrong...
So my new and main question now is: how should these values of EPDM variables be copied into file's custom properties during file opening in Solidworks? Why is it not being done automatically? I felt like this should had been a natural behavior of this system ..
I really appreciate your patience and help for new users like me.
Thank you in advance
After all this, I found the solution ...
There is no way to write variable during check out. But it is done at state change automatically. So I created a transition called "Check out and copy variables". Then I used a state "Temporary", with an automatic transition to next state. This way file moves to another state instantly, and also receives all the EPDM variables, and gets checked out.
I also used a dispatch activation "During state transition" instead of "During Check out". And so:
Target: state "Temporary"
Activation time: After change state has occured
For all documents - BLOCK START
Check out file %PathToSelectedFile% - beware that it has to be a path. IT DOES NOT WORK WITH ONLY NAME
Set card variables - any variables that are needed
End for all documents - BLOCK END
I have actually setup a Dispatch script that can indeed set the variable at checkout
Please find attached. Perhaps the issue was with an older version of dispatch?
I'm working on 2015 SP3.0 and the Dispatch script is working as it should
That said, I'm of the opinion that working with the version number on the data card is not the ideal way to manage files, since this means you will always be generating new versions. The way I see it is that you're currently using the version numbers to distinguish the differences between what you are seeing on the currently printed drawing vs what you saw on the previous printed version of the drawing, and this functionality can actually be replaced just by making good use of Revisions which have a combinative approach (e.g. A.1 or A01 etc)
I've tried this approach (using the versions) with one of my clients, and after a couple of months of struggling with it we came to the realization that this is not really a viable approach... let me explain why:
You checkout drawing A which contains Part A
Both version variables update, no problem, but a new version of the file is generated without you actually having changed anything, which means the assembly that contains the file must be rebuilt. Every time you want to cancel your changes (undo checkout), you will have to manually verify that you did not change anything on the file because EPDM will think the file contents has changed (remember that a variable change constitutes a 'change')
If you do any form of in-context design, you will be facing a repetitive rebuild problem. Part A was designed in the context of Assembly A. Everytime you checkout the part file, the version updates, causing EPDM to think the assembly needs to rebuild. The assembly is checked out, rebuilt and checked in. The assy drawing is checked out, rebuilt, and checked in, but because of this, the assembly rebuilds the part which requires the assembly to be rebuilt. So you start facing an infinite loop of rebuilding because the variables keep updating when checking out files.
The only solution to this is to checkout both the part / assy and drawing at the same time and check them in, but because you might not have checkout rights in all the states (e.g. Approved), you might not be able to perform this checkout...
So what I'm saying is... you're free to do as you wish, but just be aware of potential pitfalls later in the process
Andries thank you for sharing the experience, it is very good information.
I have been busy for months, and now I have returned to this issue trying to finish it out. To add-up to those two scenarios you have described, I would like to contribute with the following notice:
if dispatch is configured to write a variable to the file after checkout, then that particular file can not be opened in solidworks during checkout. It works like this (Solidworks is not running, checkout done via explorer window)
1. User makes "checkout out" for the document
2. Immediately after checkout Dispatch writes some variables
3. User launches solidworks and sees new values in custom properties of that file
4. User is happy
This is different if Solidworks is already running at the moment of checkout. Then we get the following scenario:
1. User makes "checkout out" for the document
2. Immediately after checkout Dispatch tries to write variables to custom properties. But it can not do it because the moment after checkout is executed, the read-only attribute is removed and Solidworks opens (reopens to be more precise) this file for writing. Because this file is now opened in Solidworks application for writing, dispatch CAN NOT write custom properties values to this file.
3. User thinks nothing has happened
It is almost the same why Dispatch can not write anything to the file before checkout - it does not have a permission to do that.
So, to sum up, this is one more reason to not have version numbers in drawings, as doing it probably would bring more confusion and increase a possibility of mistake rather than do any good.