Please advise for the below. I have configured Dispatcher for Solidworks to create JT & translation is not completing.
Below is the java error thrown in log file. I have updated required files including ACL update as per documentation.
Translation is interuppting & JT is not created.
Solved! Go to Solution.
What you're seeing is the symptom; not the cause. Dispatcher will interrupt a translation once the translation exceeds the maximum time interval set in Dispatcher assuming it is a hung task.
You need to find out what is causing the long translation time or extend the max interval to give it mroe time to translate.
I am done with similar setup on Development Environment & it is working there. in Production environment it is giving this error. Translation service starts & it takes more than 30 mins to throw the error. I tried with Admin client, where I tried to translate local sldprt file & getting below error.
Admin Client log
The system cannot find the file C:\Siemens\Disp_Root\Stage\dcproxy\U16109eb08075ac1f642c\\processmodel.txt
Compared all config files of dev & prod through Exam Diff. All seems to be same. Please advise.
I know this problem. Is you Dev Dispatcher Env on a single machine while your Production Dispatcher Env is distributed among multiple machines? If so, I know why AND have found and wrote my own solution since I just went through this problem with Siemens PLM.
The root cause is that the developers of SWIM (SPLM outsources it) did not account for the scenario of setting up SWIM Dispatcher Modules on machines other than where the Dispatcher Client and Scheduler are installed.
It assumes that the path to the staging directory is the same (local path including drive letter as well as physical location) for both the Dispatcher Client and the Modules which they aren't. This is further complicated due to the SWIM Dispatcher Module not supporting UNC paths for network file shares (although regular Dispatcher itself does) which are needed to share the staging directory from the Dispather Client server to the Dispatcher Module.
(For those already wondering why you can't just use a mapped network drive letter, it is because you cannot mount/use a mounted network drive letter and run Dispatcher Module as a Windows service. This is a well known and long time limitation of Windows.)
As a result the SWIM Dispatcher Module cannot find the files that the Dispatcher Client provides to it, gets confused, and instead looks for those file locally (e.g. C:\Windows) instead of the network share (e.g. \\server\stage). That is the cause of "system file error" message you see.
In my case, Dispatcher Client is installed on a Windows Server OS machine while the SWIM Dispatcher Module has to run on a Windows client OS because Dassault only supports running Solidworks on Windows client OSes; not server OSes. I've had run ins with them about this in the past when I had problems running SWIM Dispatcher on a Windows server OS. Their answer; "Use Windows 7 (or now 10)".
So, I've been painted into a corner by both SPLM and Dassault. Dassault wouldn't support running Solidworks on my Dispatcher Client's Windows server, and SPLM wouldn't make the SWIM Dispatcher Module work the same as a non-SWIM Dispatcher Module leaving me no option except to write my own fix which I did.
What I did was modify two files i the SWIM install directory: the swtojt.bat and the swimaux.bat. See attached.
It simply copies the staging directory files to a local path that mimicks the staging directory path on the Dispatcher Client machine, processes the files, then copies the resulting JT file back to the real staging directory for upload to Teamcenter.
I am no programmer (I just pretend to be one in this instance), and it took me only an afternoon's worth of effort to debug it, rewrite it, and test it.
I hope it solves your problem too.
BTW, I've already sent these files to the SWIM Product Manager, Paul Angier. I certainly hope that this fix is included in the next version of SWIM, so I don't have to do this every time a new version is installed.
I have tried to change the staging directory path to C:\Siemens\Disp_root\stage & permissions set for everyone to Read, write. I have updated few config files to send the TC_ERROR but I am not successul in getting email alert.
Re submitted new part to translate, observed OUTPUT file= empaty in summary of the translation in Dispatcher Client Window console, not sure this is the cause. Still i am not suceeded in creating JT file. Attached are the task logs from Dispatcher root.
When translation submitted, it downloads the prt file to staging directory, Updates the process_model.txt file.
It never calls Solidworks.exe in the back end & copies swim.xml file in runswimauxserver.bat file.
JT file is not created & hence, it is trying to upload null to teamcenter & throws error.
Attached are the task logs from Dispatcher root. Please advise.
Looks like the missing file problem is gone, right?
Looking at your module log, I see that it is now timing out.
I also see that your Solidworks CAD file has a special character in it that SWIM or SW to JT translator doesn't support. My guess is that is your next problem. Try a model without a comma in the filename to see if that joggles it to work.
You should also take a look at the SWto JT log file in the Dispatcher Stage directory for clues.
As you explained because of the different paths & uploading results file to server caused translate to fail.
We have mapped Staging directory on server (X:\Stage) & on client also we mapped staging directory as X:/Stage which is pointing to server staging directoty. After this modification we are able to create JT, where services running as console.
the same is not working when translation is submitted through client & dispatcher services running as service on Windows server / also failed when submitting as Solidworks checkin (Save JT files (dispatcher) )
Any idea how to overcome this issue.
Yes. Do not run them as Windows services. Run them (Dispatcher Module and SWIM Aux Server) as console only. That is the only way to get SWIM dispatcher to work. I've complained about this lack of functionality for a decade as well to no avail.