Batch process, BMR, Macros in OBD?

Looking at the production envionments that I am familiar with, the productivity opportunities can be split between two poles: designer / engineer and technician / drafting. I recall the old war stories where the senior architect / engineer would sit on one end of the office and do sketches, pass the sketches to the next table where the sketches would be hard lined, which would be handed to the next table for annotation, dimensioning and then down to someone like me to 'poche' and run the dyeline machine 

I would say, most of the productivity gains have been on the back end of the process... so far. AI and other next gen tech is also start to bite on the design and analytical side but that is not really a Mstn / OBD thing. Maybe an iTwin thing in future. Yes, BIM also makes a difference but underneath all the sexy demo jock examples, there is still a sea of mundane 'unstructured' data ie 'manual' tasks that will need to be addressed by some guy on a CAD workstation.

What does the aging Bentley driver have to help? I think that there will be a lot of 'kitchen triangles' involved.

Some typical architectural office tasks that are messy and traditionally involve a lot of manual effort:

Schematic design
1. Schedules
    areas
    accomodation tables
2. Drawing set up, register
3. GIS mapping backgrounds -
4. Process incoming drawings
    locate, scale, orientate drawings
    level clean up
    cell extraction
5. Scoping drawings
6. Photomontage
7. Embellishment for presentations, planning submission
    shadows
    hatching, coloured fills
    diagramming
    labeling
8. Project library updates, mangement
9. Rendering set up, materials
10. Physical models- CAD, STL export
11. Incorporation into desktop pub documents

Detailed design
1. Drawing set up: different types
2. build-up drawings
3. Details - finding, inserting modifiying manufacturers info
4. Penetrations
5. Schedules

etc etc etc

Each of these tasks will have processes that can be automated, but the cost can seem pretty out of reach... without the right tools.

1. Recording the user actions have problems: Photoshop has had Actions for a long time. Recording UI user input is a great idea, pioneered by MS Office, Excel VBA? BMR is a starting point. But problems include the range of the actions or commands that can be intercepted, and what do you do when there isn't a VBA equivalent. AutoCAD also has Macro recording, but I think AutoCAD is more rigid, text-based with its commands which is an advantage here. Maybe Microscope 2.0 can help? I suspect a bit more needs to be done at platform level, see also discussion on undo command line enhancements

And even when the commands are recorded, reading the recorded VBA project module is pretty confusing. BMR does help here by grouping and tagging the steps but it is not very flexible and does not allow the user to step into the recording and add info... apart from Place point module which 'decorates' the user's Place Datapoint commands. Need more of these for dialog or settings input, for example?

2. Looking at AutoCAD's handling of Macros, ACAD's text command line interrface allows it to feed into scripts as opposed to more verbose VBA or GCScript. See also discussions on undo, command line enhancements. The script txt format allows copy and pasting a lot better. Yes, Mstn also has a lot of keyins but not as complete or flexibly implemented / integrated with the command line compared to ACAD, Rhino, FreeCAD and Modo, for example.

BMR <> VBA

3. There needs to be a better transition between recording a macro and getting into the 'procedural' detail. Most tools will need to get into the editable, procedural mode quite quickly; and importantly, the more integrated 'procedural' tools are with the recording process the easier and less daunting the process will be. No one is going to bother if you need to enter more than 4-5 steps with piano-playing type precision. You will need to step in an correct the script a lot and iterate to check.. very early on.

BMR needs to support: 

1. Editing out unwanted user actions. This is a big barrier to adoption.
2. Adding steps in: some 'intellisense' type support would be good within the BMR dailog. Some already available in Mstns keyin dialog command tables, but it does not support the options in the settings toolboxes.
3. Add snaps: should be easy as it is a key in? What about capturing the Accudraw and ACS context, settings as well?
4. Prompts - added later, w/o having to promote to VBA
5. Daisy chaining different Macro snippets?
6. ?

Also does not support visual programming editing in the dialog view like GC.But this is probably a bridge for another day.

But what would be really good is to enhance it to allow it to better participate in daily tasks, scenarios. Sort of like Modo's Toolpipe. The BMR examples on Bentley Learn where BMR is used to semi-automate a vessel design only scratches the surface and also the problems. 

I think that one day, Mstn users working on large jobs will be starting the day by opening a file and getting a Tasks dialog with their assigned goals for the day. Each subtask - open file, ref attach dumb architect's latest model, search Design History for changes, clash detect, make mods, overlay BCF, IRS note from pesky engineer, respond to engineer etc will be laid out in loose linear 'script' which the Mstn user will be forced to drive through.

Over time, the user (or his Chatbot, or his supervisor's Cb) will be ingesting and  automating more and more of the easy bits, as it 'gets to know you' and your so-called 'work'. Eventually, you would just be along for the ride and approve or amend slightly each step before proceeding. Should be good, as it should save you having to do all that tedious autopilot stuff while you sip your coffee. Of course, you will be timed for each task and your hourly rate set accordingly... for each day. Your Cb will also take a percentage of your wages, natch. 

BMR => Batch Processor

Haven't tried this, will it take .bmrs? It would be good to test in a CC. I suppose you could auto convert the .bmr to VBA on the fly for this leg of the triangle.

I suspect that the BP will tend to come at the end of the process where the script, VBA is ready to be deployed fire and forget-style on multiple files. Looking at the typical task lists for Schematic and Detailed design, the bulk of the type of BP tasks would be at the beginning of the job or whenever we get 'foreign' data that needs to be pre-processed, converted, mapped to suit. Typical interop type stuff that is lends itself to bulk processing. Easy bit.

VBA => Batch Processor

Batch recorder takes scripts, and apparently also includes VBAs. It would be good to test in a CC

VBA needs to get more, better access to OBD/Mstn's C/C++ libraries. Its not all just messing with the non-graphic business data, which tends to be simple text-based manipulations. Yawn !

But what happens when there is user input or error-trapping required? I suppose you will need to replace or modify the VBAs (BMRs would be converted into VBAs) to handle the inputs. Instead of relying on the user to manually identify the Cell's insertion point or model 0,0 or other desired info, you would need to call on some 'smarts'... like Mstn's SelectBy, Item Types search tools. Good thing PokeIt is a VBA? It would be even more awesome if Axiom's tools would be available for bulk filtering and mods. Not sure if they have encapulated their dlls so that they can be called using VBA or even Python?

4. Need to have VBA modules for finding geometric info like centroids, nearest edges, intersections etc etc. Stuff that typically needs manual accudraw, ACS manipulation type user input.

Closer to home, it would be good to test how much of the old Triforma COM VBA methods are accessible from BMR or VBA. A bigger question is how or whether Mstn's new Parametric Solids, Constraints APIs will be accessible to VBA or will it be just C#?

But even staying with the old Triforma COM stuff, there is a lot of 'cash still on the table'. Why not GC you may ask? I think the answer is speed and scalability. GC, GH etc have a lot of overheads and are aimed at option exploration, and not optimised for more linear automation.

Hello

Top article/post. Very thought provoking.

I did dabble (very quickly) in some 'macro stuff' in MST about 15-16 years back.

This has prompted me to investigate and try it out a bit more, as I have a few ideas for little custom tools and workflows that would benefit from this sort of thing

All the best