Before You Start: Product or Sheet Template Loading

A short checklist to work through before starting either kind of development work covered by this project's tutorials: Product Loading (building BIM components) or loading Dynamic Sheet Templates (building rule-driven drawing sheets). Part 1 applies to both. Parts 2 and 3 cover what's specific to each.

A data pool is DigiPara Liftdesigner's separate storage location for your program data (component library, projects, sheet templates, and settings), managed via Poolmanager (Start → Programs → DigiPara → DigiPara Liftdesigner → DigiPara Liftdesigner Poolmanager). Create a new, dedicated data pool for this work — via Poolmanager's Add button → data pool wizard → Create a new data pool — rather than doing it in your everyday default pool. This keeps your existing/default data pool free for ordinary project and testing work once you're done. See "Creating a Data Pool."

Neither Product Loading nor DST configuration is "finish everything in one application, then move to the other" — both are a back-and-forth: edit or configure data in the Datamanager, switch to Liftdesigner to load and test the result, then switch back to adjust. Keep both applications open together rather than closing one before opening the other.

Know your way around the DataManager application before configuring anything in it — see What Is the Liftdesigner Datamanager?. In particular:

Both a component library and a DST are exported and shared as a single .ldm12 file, registered via the MODULE FILES table. To share your work: export it via Datamanager, then find it in the data pool's Export folder. To load a module someone else shared: close all DigiPara Liftdesigner applications first, then place the .ldm12 file in the data pool's Import folder before reopening any DigiPara Liftdesigner application. This manual process is frequently used during development, as not every intermediate version needs to be uploaded to the DigiPara Liftdesigner Cloud for an official release.

LD-Developer (75) is fine to practice in, but it's a shared training module — it gets overwritten with every DigiPara Liftdesigner update. Anything you actually need to keep belongs in your own manufacturer module (see the next point), not in 75.

A manufacturer module needs a unique manufacturer RID number so it doesn't collide with DigiPara's own library or anyone else's — this applies equally to a component library and to a DST module. Request your own RID number (and manufacturer module) from DigiPara directly, rather than reusing the shared training module.

An .ldm12 file is the exported, shareable package of one manufacturer module's data — everything under that manufacturer's RID range, bundled into a single file for import into another data pool. A manufacturer RID is the unique numeric block DigiPara assigns to that manufacturer; every record you create — a component or a DST configuration table row alike — gets its RID from within that block.

Write down what you did and why, particularly wherever you've defined your own logic — a component's user parameters and dynamic BIM Component Rules, or a DST's frame group / sheet group / constant group rules. None of that logic is self-explanatory to the next person (including future you). Use the Datamanager's Annotate docking window to attach a comment directly to the relevant data row.

Every database column used across the Product Loading tutorials is documented in the Component Data Reference — one article per table (e.g. L_CarFrameTypeTab, L_GearArtTab, L_PitBaseUnitTab). Check it before you rely on a field name alone. You don't have to leave the Datamanager to reach it: click a table cell to see a short description in Quick Help, or press F1 on a cell to jump straight to that column's Component Data Reference article.

The developer .dwg reference drawings that several Product Loading tutorials load automatically are stored in your data pool, under ...\dcc\DataPool\developer\dwg. (This is a different use of "DWG" from the drawing border/title block files used in DST work — see point 13.)

CAD models are the recommended approach mainly for static components — ones that don't need to resize or reshape themselves, such as a door fixing, a guide shoe, or a governor. For components that must adapt to project-specific dimensions, native Liftdesigner profiles (or CAD occurrences converted to profiles) are usually the better fit — see the CAD Models tutorial for how to combine both approaches on the same component.

A DST's view frames often need dimension lines that aren't part of Liftdesigner's standard set. Before building a DST, know how to define characteristic points for your own dynamic dimensions on a component, and how to draw a dimension from those points using the Dimensions ribbon tab's Dynamic Dimensions group (Aligned Dimension, Vertical Dimension, Horizontal Dimension).

Every change you make directly on a view frame — a dimension change, a component visibility change, an annotation change — is recorded in that view frame's Overwrites list, rather than changing the view frame's underlying template. This is what lets you make a project-specific tweak (for example, hiding the holes under the shaft, as the B2 tutorial does via the View Frame Overwrites *operator) without altering the base view frame everyone else's projects also use. Check the View Frame Overwrites docking window whenever a view frame needs a one-off adjustment that shouldn't be baked into the reusable template.

A DST is built from view frames, so know how to add the view type you actually need before configuring rules around it. The View Frame ribbon tab lets you add plan views, vertical sections, machine room views, sheave views, wall opening views, and more — each with its own component visibility and dimension settings.