TheSwamp
CAD Forums => CAD General => Topic started by: Peter2 on October 30, 2015, 03:12:19 AM
-
If I use AutoCAD, start a huge script (which runs for hours to create PDF) and I "log of" from the PC, AutoCAD will be cancelled.
Is there a way to keep it alive (running the script) anyhow?
-
How big is this job that it takes that long or is it a low powered computer?
-
If I use AutoCAD, start a huge script (which runs for hours to create PDF) and I "log of" from the PC, AutoCAD will be cancelled.
Is there a way to keep it alive (running the script) anyhow?
Why not simply lock the computer? There is no way that I know of to run AutoCAD while in a logged off state. In fact on Windows, only core applications will run headless or without a user.
-
How big is this job that it takes that long or is it a low powered computer?
No, it is not one big job, it was a simplified question. The idea behind is to run a monitoring tool which starts AutoCAD sometimes.
Why not simply lock the computer? ...
This is what I suggested to the client. But I asked here to confirm that a logged off computer will not run ....
-
How are you running the monitoring tool?
-
At the moment there is a chain "Monitoring - ScriptPro - AutoCAD - Printdriver". All works fine when PC is locked, but nothing works if logged off. Now the discussion is to modify the monitor to a "Service" (not easy to do ...), but I'm believe it does not make sense to modify the first step in the chain when steps 2 - 4 have the same problem.
-
I believe ScriptPro is driven by a batch file, therefore, out of interest, is ScriptPro closing/opening a new instance of AutoCAD for every drawing? If so, this is not necessary and will obviously greatly increase the time required to process the drawings.
-
Logging off/out of a given user account, stops all applications (i.e., Processes) the user has/had running. Period.
If the client now needs for the automation to run as a Service (not necessarily an actual Service, of course), then the client workstation (aka user account) needs to initiate the Process via an interface with said Service running on a Service host (another machine, presumably a server, or workstation dedicated to same, which has it's own implicit licensing requirements).
You'll need to automate/schedule the start of the monitor Process (Service) on the Service host, and reconfigure your app suite to 'watch' for incoming requests from one or more clients, and implicitly configure clients to have sufficient AD/Share/NTFS permissions to 'post' the request wherever the Service host is 'watching', if that makes sense.
Same goes for the return process, or completion of same - the Service host now also requires sufficient AD/Share/NTFS permissions to write the data to appropriate locations either locally on the Service host, on the network, and also to send the resultant output to the printer, etc.
To boot, you must ensure that the Service host 'always' has the appropriate mapped network drives, and printer connections - I'd recommend the latter be performed via Group Policy using Print Management (printmanagement.msc + gpmc.msc are your friends), specifically setting the Printer's Deployment with a Connection Type of 'Per Machine' so that the connection is made available when the machine starts/restarts prior to any user account being logged on.
HTH
-
... is ScriptPro closing/opening a new instance of AutoCAD for every drawing?...
No. The first release did it in this strange way, but release 2 (which is already some years old)...
- starts and close once at the beginning
- and runs all jobs like a script-file: one after the other
...on a Service host (another machine, presumably a server, or workstation dedicated to same, which has it's own implicit licensing requirements)....
So, to say it in simple words for simple users:
- it is complicated to
- move the problem from the first machine to the second one ....
Thanks BlackBox, I think this is enough information to show that this topic should be solved in another way (simplest one: lock instead logg of)
Thanks to all!
-
I'm always happy to not help :-)... Not fixing what isn't broken, is indeed the simplest solution... I felt that to be adequately stated by others, so I thought I'd help to clarify the other side of the coin (which sounds harder then it really is, BTW).
That said, your app deployment should be only as complex as necessary to do the job well, in terms of accurate and efficient operation, in addition to meeting a client's requirements.
Cheers
-
...
- should be only as complex as necessary to do the job well,
- in terms of accurate and efficient operation,
- in addition to meeting a client's requirements.
Sometimes the first two targets are easier to reach...
Thanks again.