The Automation Hub

Your team's own scripts, in one catalogue, run by name from chat on the CAD system you have open. Import a SOLIDWORKS macro, an Inventor iLogic rule, an NX journal, a Solid Edge macro or a compiled .NET assembly once, and from then on anybody can run it without opening a code editor.

What it holds

The hub is a catalogue of scripts that already exist. It does not write them and it does not translate them: a SOLIDWORKS macro stays a SOLIDWORKS macro. What the hub adds is a name, a description, the parameters it takes, and a single way to run any of them from the chat.

Importing

One file

The file is copied into your own hub folder, so moving or deleting the original afterwards does not break the catalogue entry. An import that lands on a name already in use keeps both: the second copy is stored under a timestamped file name.

A whole folder

Each file becomes its own catalogue entry, and the answer is one line per file naming the CAD system and the type it was filed as. Read that list before you run anything: a rule filed under the wrong CAD system is the one failure that looks like a broken script.

A pack somebody sent you

A .sphereharness-pack file carries skills, automations and macros together. What happens when a name already exists, and why a pack is sometimes refused outright, is covered in Macros and in the libraries help inside the product.

A note on SOLIDWORKS .swp files

A .swp is usually a compound binary file rather than plain text. On import its VBA source is read out of the file so you can ask about it later, and the macro is not run to get at it. What you can read back is what was really in the file: a macro whose stored module text is only a fragment is treated as having no readable source rather than being handed on as if it were the macro.

The second thing to know about a recorded .swp is about running it, not importing it. A macro recorded against one model often picks its geometry by a reference stored in that model. On a different part the selection finds nothing and the next line fails, typically with VBA's Run-time error 91. Three of five real recorded macros behaved exactly that way in testing. They are not broken; they need a selection, so select the face or edge first and then run.

Running one by name

Asking for the details first is worth the extra prompt. It lists the parameters the automation declares, with their types and defaults, and for a .NET assembly it also lists the methods the assembly offers. The automation runs on the CAD session you have open; when more than one CAD is running, say which, or set the Target.

When a script needs something you did not give it

Three different things are meant by "needs input", and each is answered in a different place:

• A declared parameter with no value. You are asked for it by name before anything runs. Give it in the same sentence next time: run "Export STEP" with folder C:\parts.
• A selection. A recorded macro that starts from a selected face or edge cannot be given one in a sentence. Select it in the CAD window, then run. If it runs anyway and fails on its first selection, that is what has happened.
• A method, on a .NET assembly. See the next section: you are shown what the assembly can actually run, and asked which one.

.NET assemblies

A compiled assembly is the one kind of automation that can hold dozens of separate entry points, so it works slightly differently from a macro.

Name the method and it runs

A fully qualified Namespace.Class.Method is run directly. One call, no list, no extra round trip. Arguments you name are matched to the method's parameters, and a value that matches no parameter of the method is reported back to you rather than quietly dropped.

Do not name one and you get the list

When nothing resolves to a method, nothing runs, and what comes back is the assembly's callable methods, one line per class, with each method's parameters and return type. The likely entry points are listed first and marked. On AutoCAD the marked name is the command name the assembly registers, which is what actually runs. You then say which one you want, and that second request runs it.

AcadSample.dll: 4 executable methods (* = entry point; a:int? = optional; app/doc/db/ed/session/part are supplied by the CAD):
AcadSample.Shapes: SHDEMOCIRCLE*(); SHDEMOLINES*(); CountModelSpace(db:db)->int; DrawSquare(db:db,sideMm:double)->int
Nothing was executed.

Parameters the CAD supplies for itself, such as the application, the document, the database or the NX session, are shown as their short token and are not yours to fill in. A parameter with a trailing ? can be left out. A long assembly is capped and you are told how to narrow the list, and if you named a class that exists and a method on it that does not, the list is narrowed to that class automatically.

Siemens NX: journals play in the session you are sitting in

An NX journal runs inside your open NX session, on the work part. You watch it happen and you undo it the way you undo anything else. A journal that reads the work part when no part is open is refused before it plays, with that reason, rather than being run into a null reference.

When a journal fails, you get the journal's own exception and its own line number, not a generic "failed to replay" message. A compile error comes back as NX's own compiler text. Neither puts up a dialog.

A journal cannot be interrupted once NX has it, so there is no timeout. The elapsed time is reported instead. Expect the first play in a session to take a few seconds longer than the ones after it, because the compiler and the runtime start up on the first one.

AutoCAD: an assembly outside a trusted folder is refused

AutoCAD decides for itself which folders it will load code from, through its SECURELOAD and TRUSTEDPATHS settings. SphereHarness checks that policy before loading anything:

• SECURELOAD 0 loads from anywhere, and the check does nothing at all.
• SECURELOAD 1 or 2 with the assembly in a folder that is not trusted: the request is refused by name, nothing is loaded, and nothing runs. No dialog appears. Loading it would have raised AutoCAD's own File Loading - Security Concern prompt, and nothing here may answer a security prompt on your behalf.

The fix is yours to make, in AutoCAD, and it is the same fix you would make to run the assembly by hand: add the folder to Options → Files → Trusted Locations (the TRUSTEDPATHS setting), or move the assembly into a folder that is already trusted. A path entry names one exact folder unless it ends in \..., which includes its subfolders; AutoCAD's own install tree and the ApplicationPlugins folders are trusted already. The refusal names the folder and the current setting value, so you can see which of the two to change.

"It ran" is never the answer

A script that returns without an error has not necessarily done anything. Every run is judged by reading the document before and after, and you are told the difference:

Three outcomes follow from that, and they read differently on purpose:

• It ran and changed the document, with the deltas: features 17->19, bodies 0->1, volumeMm3 0->10800.
• It ran, changed nothing. The script returned no error and the measured document is identical: ran and reported no error, but the document is UNCHANGED - ran, changed nothing (features 19, bodies 1, volumeMm3 2000). This is the honest answer to a script that silently did not apply, and it is never reported as a success.
• It failed, with the script's own error, plus the read-back taken at the moment it failed. A script that built half of what it intended before throwing says so, and the half that exists is reported.

Sharing with your team

Your catalogue is local. Imported scripts live in your own folder on your own PC, and nothing about them is sent to any server unless organisation sharing is switched on. The server holds your account, your licence and your usage, not your team's scripts.

To get a script to a colleague:

• Export a pack. One .sphereharness-pack file you can email or put on a share. It is an ordinary zip with a manifest inside, so you can look at what you are about to send.
• They import it. Importing writes files and runs nothing.
• Or switch organisation sharing on, and your organisation's server carries the library instead. That is one setting, it is off by default, and with it off nothing in these libraries makes a network call at all.

Use case: a folder of somebody else's scripts, running from chat

A four-person design team has scripts nobody currently maintains: a folder of iLogic rules a former colleague wrote, three NX journals recorded for a project last year, and one AutoCAD assembly a contractor delivered with no documentation. Nobody runs them because nobody remembers how. Here is the whole path, with the sentences typed and the answers that came back.

1. Get them into the catalogue

Fifteen files went in and fifteen catalogue entries came out, each naming the CAD system and the type it was filed as: five NX journals, five Inventor rules, five SOLIDWORKS macros. The five Inventor rules were plain .vb files, and were filed as Inventor rules rather than NX journals because the code named Inventor's own objects.

Answer: Found 15 automation(s), and filtering by CAD system gives 5, 5 and 5. A search for extrude found four, across two CAD systems, which is the point of a catalogue rather than a folder.

2. Run an Inventor rule

The first rule stamps a drawing's title block. Ask what it does before running it:

The rule ran, and the answer did not stop at "it ran": the part's properties were read back afterwards, and Checked By and Date Checked now hold values that were empty before. The two other stamping rules in the folder behaved the same way, and each left the other rules' properties untouched, which is what a read-back can prove and a status code cannot.

One rule in that folder does not run at all: it is a VBA macro that somebody saved with a rule's extension, and Inventor refuses it in its own words, naming the structure it expected. That refusal is the script's, not ours, and it arrives verbatim.

3. Run the NX journals, including the one that fails

It played inside the open NX session, on the work part, and the answer read sketches 0->1, bodies 0->1, volume 912 000.000000 mm³, in 2.9 seconds. The rectangle journal gave sketches 0->1, features 1->3 in 2.7 seconds. Both are visible in the session and undoable.

This one fails, and the useful part is how it fails:

The journal itself threw: System.NullReferenceException ... journal0.cs:line 38

Line 38 is line 38 of the team's own journal file, and it is theSession.ActiveSketch.FindObject("Origin"). So the journal is not broken: it is a fragment recorded from inside an open sketch, and it needs a sketch already active. The part was left unchanged, which was measured rather than assumed. Ten minutes of guessing became one line of evidence.

4. Run the contractor's AutoCAD assembly, without documentation

Nobody knows what is in the assembly, so do not pretend to:

Four callable methods came back, two of them marked as AutoCAD commands, each with its parameters. Nothing was loaded to produce that list and nothing ran. Now pick one:

Answer: ran and CHANGED the document: modelSpaceEntities 0->1. From here on you do not need the list. The name is known, so name it:

One call, no list: modelSpaceEntities 0->4, extentsX (unset)->40, extentsY (unset)->40. It returned: 4. Four entities for a square, extents of 40 for a side of 40, and the method's own return value of 4. Three independent things agreeing is what makes it safe to put on a schedule.

5. And when a script quietly does nothing

The same team has a SOLIDWORKS assembly with a method that was supposed to modify the part. It returns cleanly. The answer is still not a success:

'SwSample.dll!SwSample.Bosses.Touch' ran and reported no error,
but the document is UNCHANGED - ran, changed nothing (features 19, bodies 1, volumeMm3 2000).

Compare that with the run before it on the same part, which reported features 17->19, bodies 0->1, volumeMm3 0->10800 for a 30 by 30 by 12 boss. 10,800 mm³ is exactly 30 × 30 × 12, so the millimetre conversion inside somebody else's assembly and the measurement of the result agree. That is the check worth making on any script you did not write.

What the team ended up with

• Fifteen scripts anyone can now run by name, on the CAD system they belong to, from the same chat.
• One journal correctly identified as needing an open sketch, with the line number that says so.
• An undocumented assembly reduced to four named methods, one of which is now used daily.
• Nothing sent anywhere: the catalogue is on the machine that runs it, and what leaves is a pack, when somebody exports one.

See also

• Native Macros & Automation - recording in the CAD system's own format, scheduled tasks and driving a command dialog.
• Macros - SphereHarness's own recorded macros, which need no code at all.
• Verifying Results - why a read-back is the answer and "it ran" is not.
• Siemens NX · AutoCAD · SOLIDWORKS · Inventor · Solid Edge
• Support requests - if a script will not run and you want somebody to look at it.