Check whether the given MIDAS NX product is reachable through the Open API.
Returns the connection status and the program name. A blocked NX session
(an open dialog) can still report "connected"; a later read then times out.
Parametersproductrequired
List the tables this server can read: /db model data (e.g. "NODE") and
/DESIGN design parameters (e.g. "DESIGN/STEEL/DSTL", the steel design code).
product: keep only tables that product supports. search: case-insensitive
text matched against the table name and title, e.g. "load", "section",
"design". No NX call is made.
Parameterssearchproduct
The NX server's own field schema for one /db table (GET /info/db/<TABLE>).
Call this before read_table to learn what each field means.
Parameterstablerequiredproductrequired
Records of one table in the open model, e.g. table="NODE" or "DESIGN/STEEL/DSTL".
ids: return only these record ids. limit: at most this many records
(capped by the server's MIDAS_MAX_ROWS). The reply says how many records
the table holds in all, so a truncated answer is never mistaken for the
whole table.
Parametersidslimittablerequiredproductrequired
Record counts of the main tables (nodes, elements, materials, sections,
thicknesses, static load cases), plus the model's unit system.
A table that fails to read is reported with its error, the rest still count.
Parametersproductrequired
Model-wide information NX computes, not stored in a table.
what: "project_status" (counts of model and load data), "section_properties"
(computed area, inertia, ... per section id), "story_check_parameter" and
"story_irregularity_parameter" (Gen only), or "selection" (what the user
has selected in the NX window now). Entries keyed by id are capped like
read_table.
Parameterswhatrequiredlimitproductrequired
List the result/report table types result_table accepts, by category.
Categories: "model" (mass, weights, loads, sections, supports; no analysis
needed), "analysis" (reactions, displacements, member forces, stresses,
modes), "story" (Gen: story drift, displacement, shear, stability,
irregularity checks), "design" (design member forces). Each category says
what NX needs before its tables have data.
search: case-insensitive text matched against the type and its name,
e.g. "reaction", "beam", "drift". No NX call is made.
Parameterssearchcategory
One result table from the open model (POST /post/TABLE, nothing exported).
table_type: from list_result_tables. Common ones: "REACTIONG" (support
reactions), "DISPLACEMENTG" (nodal displacements), "BEAMFORCE" (beam/column
member forces), "PLATEFORCEL" (plate forces), "EIGENVALUEMODE" (periods and
modes), "STORY_MASS" / "STORYWEIGHT" (story mass and weight, no analysis
needed), "STORY_DRIFT_X" / "STORY_DRIFT_Y" and "STORY_SHEAR_FOR_RS" (Gen
story checks), "BEAMDESIGNFORCES" / "COLUMNDESIGNFORCES" (design forces).
load_cases: names with a type suffix, e.g. ["DL(ST)", "COMB1(CB)"]; the
model's load cases are in read_table("STLD"). components: column names to
keep. keys: node or element ids to restrict to. Rows beyond limit (capped
by MIDAS_MAX_ROWS) are counted, not returned.
Parameterskeyslimitproductrequiredcomponentsload_casestable_typerequired
A PNG of the model window as NX shows it now (POST /view/CAPTURE).
Shows the current view: viewpoint, active elements and result display are
whatever the user has set in NX; this tool does not change them. width and
height are in pixels (each at most 2000); leave them out for the window size.
Parameterswidthheightproductrequired
Show an analysis result in the NX window and return it as a PNG.
Like picking a result under Results in NX (POST /view/RESULTGRAPHIC, then
/view/CAPTURE): the window keeps showing it afterwards. The model and its
results are not changed. Needs the analysis run in NX.
result and its components (default first):
"reactions" FZ, FX, FY, MX, MY, MZ (values are always shown)
"displacement" DXYZ, DX, DY, DZ (contour)
"deformed_shape" DXYZ, DX, DY, DZ (deformed over undeformed)
"beam_diagram" My, Mz, Fx (axial), Fy, Fz (shear), Mx (torsion)
"plate_forces" Mxx, Myy, Mxy, Fxx, Fyy, Fxy
load_case: a name from read_table("STLD"), e.g. "DL"; a combination with
its type suffix as result_table takes it, e.g. "gLCB1(CB)", "cLCB1(CBC)".
show_values writes the numbers on the picture; deform_scale scales the
deformed shape (NX's own scale when left out). width/height: pixels, at
most 2000 each.
Parameterswidthheightresultrequiredproductrequiredcomponentload_caserequiredshow_valuesdeform_scale
Run the analysis in NX (POST /doc/ANAL). Two steps: preview, then apply.
NX saves the open document over its file before analysing (leaving a .bak),
unsaved changes included, even when it then refuses the analysis. So this
needs a document that has been saved before, seen in the NX window title on
this PC; a new, never-saved document would raise a Save As dialog that
blocks NX, and is refused here.
Parametersproductrequiredconfirm_token
Save the model as a new file in the output folder (POST /doc/SAVEAS).
Two steps: preview, then apply.
Like Save As in NX: from then on NX works on the copy, so the window, later
saves and run_analysis use it, and the original file stays as it was last
saved. The name is generated (mcp-save-<product>-<time>, .mgbx for Gen,
.mcbz for Civil). Also the way to give a never-saved document a file, which
run_analysis needs.
Parametersproductrequiredconfirm_token
Create or update records in one /db or /DESIGN table. Two steps: preview, then apply.
records: {id: fields}, e.g. {"13": {"X": 0, "Y": 0, "Z": 6.4}} for NODE; see
describe_table for the fields (or read_table, for /DESIGN). "create"
refuses ids that exist, "update" ids that do not, except record "1" of the
one-record /DESIGN tables DCO, DCTL, LLRF, LMRR and SRDF, which have no
create and are made by their first update. At most 50 records. After applying, the
table is read back and what actually changed is returned; some tables store
a new record under an id of their own choosing, so trust "added", not the
ids you sent; the preview says when a table is known to do that. A record
naming one that does not exist (an element's material, section, thickness
or nodes, a load's load case or group, ...) is refused: NX would refuse
it, store it pointing at nothing, or drop the value (midas-nx
plan.validate). Any write discards the analysis results.
Parametersmoderequiredtablerequiredproductrequiredrecordsrequiredconfirm_token
Delete records by id from one /db or /DESIGN table. Two steps: preview, then apply.
Only the listed ids, one DELETE per id; there is no way to empty a table
here. Nodes still used by an element are refused (NX would delete the
elements with them), and so are materials, sections and thicknesses still
used by an element (NX would leave the elements pointing at nothing). The
preview names the other records NX deletes or empties along with these:
a load case's loads and combination entries, a node's nodal loads,
supports and masses, an element's beam loads, end releases and pressure
loads (midas-nx plan.validate). At most 50 ids. The table is read back afterwards: on some /DESIGN tables NX resets
the record to defaults rather than removing it, or keeps it unchanged, and
the result says which; records NX removed from other tables are counted.
Parametersidsrequiredtablerequiredproductrequiredconfirm_token
Create, update and delete records in several tables at once, e.g. the
materials, sections, nodes, elements, load cases and loads of a small model.
Two steps: preview, then apply.
Each operation is what write_records or delete_records would take: table,
action ("create", "update" or "delete"), and records ({id: fields}) or ids.
The steps are run in midas-nx's dependency order (deletes first, then
what is named before what names it), whatever order they are given in;
the preview shows that order. The preview checks the whole batch first,
with the records earlier steps create counted as existing: the same rules
as write_records and delete_records. A UNIT change is not taken here.
At most 20 operations and 200 records in all.
Applying runs the steps one by one and reads each table back. It stops at
the first step that fails, changes nothing, or stores new records under
other ids while a later step names that table; what was already applied
stays (nothing is rolled back) and the result lists the steps done, the
failed one, and the ones not run. Any change discards the analysis results.
Parametersproductrequiredoperationsrequiredconfirm_token
generate_load_combinations
Have NX add its KDS design load combinations. Two steps: preview, then apply.
kind: "concrete" (KDS 41 20 : 2022, into LCOM-CONC), "steel" (KDS 41 30 :
2022, LCOM-STEEL) or "src" (KDS 41 SRC : 2022, LCOM-SRC). NX builds the
combinations from the model's static load cases and their load types and
appends them (cLCB1, cLCB2, ... for concrete); the existing ones stay.
Gen NX only: Civil NX has no such command. After applying, the table is
read back and the combinations NX added are returned. Any change discards
the analysis results.
Parameterskindrequiredproductrequiredconfirm_token