Batch Utility Navisworks

[Adah Orhenkowski]

Ihave my Batch setup to run 3 times a day. It was all set to go for sat and sun. I should have had 6 nwds when I came in this moring and I had none. I just wondering what I am doing wrong. Attached is my "schedule" file and the exported task from the Task Scheduler.

So I tried doing the setup again. When I was done I clicked on Run command and it worked fine. So I then Scheduled the command and its still doing nothing. Task Scheduler says it ran and completed but it never gave a output file and didnt add anything to the .log file.

Not that I know of. The limitation as far as I can tell is in the Windows Scheduled Task Manager. It calls processes with a command line, and if you inspect the task for the batch utility you'll see it can be quite long when the path is taken into consideration. Can you use some local NWF files? You shouldn't need to copy the entire project, just have the relevant files merged into those NWF files and point each batch process at those.

This seems to be working, although I did have to make new folders on the network farther up the tree to get it to save to that location. But I can see the higher ups not being happy about the folder move for the models.

As for the output folders, you could output to a local folder as well, and set up Robocopy or other utility to auto-copy the output where it should be. Not ideal, I agree. I've run into the problem as well so I'll try to remember to file it for the next round of BETA testing. Reporting this as a bug to Microsoft might help, but with Win 10 looking like the next Win 7 (which itself is nearing end-of-life for support updates) we may not see a fix there.

If it is a Windows limitation there might not be anything that can be done right away. They'd pretty much have to create their own service application to run in the background, duplicating the Scheduled Task Manager features.

i just had a similar issue. to resolve it i edited the text that has the list of files to be converted to include the full UNC path. This seems to have resolved the issue for me. like a previous post mentioned, the Batch Scheduler does not seem to like Network paths.

I would like to setup an automated process turning my BIM 360 document into a Navisworks .nwd file every night after work. Before we used BIM 360, I was able to locate the file path of the rvt to automatically load throught the batch utility in Navisworks. Now that we are using BIM 360, I am unable to find locate the file uploaded to the BIM 360 server.

Thanks for participating in the community! I believe this is able to be done if you path the Batch utility through the Desktop Connector drive. This allows for you to publish the Navisworks files into your preferred folder within your BIM 360 account.

This will work as you suggested if I use the Desktop Connector to path the revit file. It WILL NOT work if I 'Collaborate in Cloud' with the Revit model. When this collaboration process is 'Initiated' I lose all access to the file through Desktop Connector, as the file will just not show up in any file explorer.

I'm trying to run a software's batch utility tool via C# and the command line but am not able to get it to work. I am able to build a string which is correct and works when I just copy and paste it into the command prompt, but when my code tries to do that step automatically nothing happens; the script just runs to the end and nothing happens.

A batch file is a script file in DOS, OS/2 and Microsoft Windows. It consists of a series of commands to be executed by the command-line interpreter, stored in a plain text file. A batch file may contain any command the interpreter accepts interactively and use constructs that enable conditional branching and looping within the batch file, such as IF, FOR, and GOTO labels. The term "batch" is from batch processing, meaning "non-interactive execution", though a batch file might not process a batch of multiple data.

Similar to Job Control Language (JCL), DCL and other systems on mainframe and minicomputer systems, batch files were added to ease the work required for certain regular tasks by allowing the user to set up a script to automate them. When a batch file is run, the shell program (usually COMMAND.COM or cmd.exe) reads the file and executes its commands, normally line-by-line.[1] Unix-like operating systems, such as Linux, have a similar, but more flexible, type of file called a shell script.[2]

A .bat file name extension identifies a file containing commands that are executed by the command interpreter COMMAND.COM line by line, as if it were a list of commands entered manually, with some extra batch-file-specific commands for basic programming functionality, including a GOTO command for changing flow of line execution.

Microsoft Windows was introduced in 1985 as a graphical user interface-based (GUI) overlay on text-based operating systems and was designed to run on DOS. In order to start it, the WIN command was used, which could be added to the end of the AUTOEXEC.BAT file to allow automatic loading of Windows. In the earlier versions, one could run a .bat type file from Windows in the MS-DOS Prompt. Windows 3.1x and earlier, as well as Windows 9x invoked COMMAND.COM to run batch files.

The IBM OS/2 operating system supported DOS-style batch files. It also included a version of REXX, a more advanced batch-file scripting language. IBM and Microsoft started developing this system, but during the construction of it broke up after a dispute; as a result of this, IBM referred to their DOS-like console shell without mention of Microsoft, naming it just DOS, although this seemingly made no difference with regard to the way batch files worked from COMMAND.COM.

OS/2's batch file interpreter also supports an EXTPROC command. This passes the batch file to the program named on the EXTPROC file as a data file. The named program can be a script file; this is similar to the #! mechanism used by Unix-like operating systems.

Unlike Windows 98 and earlier, the Windows NT family of operating systems does not depend on MS-DOS. Windows NT introduced an enhanced 32-bit command interpreter (cmd.exe) that could execute scripts with either the .CMD or .BAT extension. Cmd.exe added additional commands, and implemented existing ones in a slightly different way, so that the same batch file (with different extension) might work differently with cmd.exe and COMMAND.COM. In most cases, operation is identical if the few unsupported commands are not used. Cmd.exe's extensions to COMMAND.COM can be disabled for compatibility.

COMMAND.COM and cmd.exe support special variables (%0, %1 through %9) in order to refer to the path and name of the batch job and the first nine calling parameters from within the batch job, see also SHIFT. Non-existent parameters are replaced by a zero-length string. They can be used similar to environment variables, but are not stored in the environment. Microsoft and IBM refer to these variables as replacement parameters or replaceable parameters, whereas Digital Research, Novell and Caldera established the term replacement variables[5] for them. JP Software calls them batch file parameters.[6]

This example batch file displays Hello World!, prompts and waits for the user to press a key, and then terminates. (Note: It does not matter if commands are lowercase or uppercase unless working with variables)

To execute the file, it must be saved with the filename extension suffix .bat (or .cmd for Windows NT-type operating systems) in plain text format, typically created by using a text editor such as Microsoft Notepad or a word processor working in plain text mode.

The interpreter executes each line in turn, starting with the first. The @ symbol at the start of any line prevents the prompt from displaying that command as it is executed. The command ECHO OFF turns off the prompt permanently, or until it is turned on again. The combined @ECHO OFF is often as here the first line of a batch file, preventing any commands from displaying, itself included. Then the next line is executed and the ECHO Hello World! command outputs Hello World!. The next line is executed and the PAUSE command displays Press any key to continue . . . and pauses the script's execution. After a key is pressed, the script terminates, as there are no more commands. In Windows, if the script is executed from an already running command prompt window, the window remains open at the prompt as in MS-DOS; otherwise, the window closes on termination.

Variable expansions are substituted textually into the command, and thus variables which contain nothing simply disappear from the syntax, and variables which contain spaces turn into multiple tokens. This can lead to syntax errors or bugs.

The usual way to prevent this problem is to surround variable expansions in quotes so that an empty variable expands into the valid expression IF ""=="bar" instead of the invalid IF ==bar. The text that is being compared to the variable must also be enclosed in quotes, because the quotes are not special delimiting syntax; these characters represent themselves.

The delayed !VARIABLE! expansion available in Windows 2000 and later may be used to avoid these syntactical errors. In this case, null or multi-word variables do not fail syntactically because the value is expanded after the IF command is parsed:

Another difference in Windows 2000 or higher is that an empty variable (undefined) is not substituted. As described in previous examples, previous batch interpreter behaviour would have resulted in an empty string. Example:

Unlike Unix/POSIX processes, which receive their command-line arguments already split up by the shell into an array of strings, a Windows process receives the entire command-line as a single string, via the GetCommandLine API function. As a result, each Windows application can implement its own parser to split the entire command line into arguments. Many applications and command-line tools have evolved their own syntax for doing that, and so there is no single convention for quoting or escaping metacharacters on Windows command lines.

3a8082e126