LISP: How to detect Sheet Metal and BIM license and component type?

Roy Klein Gebbinck

For a LISP+ODCL based 'Dwg-Browser-Inserter' application I would like to be able to choose the correct insert command in case a drawing is a parametric component. Finding out if a drawing is such a component is not the issue (extension dictionary of model space => "ACAD_ASSOCNETWORK"). And the LICKEY variable provides information about the license level (Classic/Pro/Platinum).
But how do you:
1.
Detect if a BricsCAD 'Vertical', Sheet Metal and/or BIM, is licensed?
2.
Detect the difference, if any, between a BMech, BIM and Sheet Metal component?

Vaidas Guogis

 I don't know exact way how to check that, but like a raw idea, how I'm checking Windows user is an administrator or not. I try to write something to HKLM, then trying to read it. The same can be made for components - try to create an object then check is it created.

Roy Klein Gebbinck

Thank you for your answer Vaidas. I am not sure if this is exactly what you mean, but it would be possible to call a Sheet Metal or BIM command and then check with the CMDACTIVE variable if the command is in fact functional. But that is a little clunky IMO.

BTW: My first post contains an error: To check the license level the LICFLAGS, and not the LICKEY, variable should be used.

Jason Bourhill

Hi Roy,

BricsCAD uses the Reprise license manager , I assume that there must be a method to query it to determine what licenses are installed, which would be the definitive way.

The LISP developer support package has been updated, which allowed me to determine the following options

Sheetmetal
With V17 you can now test for Sheetmetal using (smlispget "CheckSheetMetalLicense").

BIM
Unfortunately there is no LISP API for BIM (yet??). However you can now use (getcfg "Name") to read any SETTINGS variable. If you deactivate the BIM module you will notice that its options disappear from SETTINGS. Bit of a cludge, but you can test for the presence of one of these variables to determine if BIM is available. e.g. (getcfg "SkpStitch") returns 0 or 1 if BIM is enabled, returns NIL otherwise.

Communicator
??

In addition to checking that a valid license is available, you would also need to check the respective run as state. There are three variables to check, RunAsLevel, UseSheetMetal, UseBIM. These variables allow the user to force BricsCAD at a particular level.

Attach a LISP function that utilises the above to determine level and modules.


Regards,

Jason Bourhill

CAD Concepts

getbricscadtype.lsp

Roy Klein Gebbinck

Thank you for your information Jason. I am still using the old LDSP, so I will definitely download the new version.
'Guessing' how a user wants to insert a drawing may prove to be impossible:
1.
In case of a 'normal' dwg use Insert or Xref (attach or overlay)?
2.
What if a user has a BIM license but wants to use BmInsert in a particular case?
3.
A 'static' component can also be BmInserted/BimInserted.

And, apart from checking 'Run As' states, existing references would also need to be analysed.
I definitely have some more thinking and research to do...

Torsten Moses

Dear All,

I just added a new BricsCAD-specific LISP function :
(BCAD$LicenseLevels)

it returns the actual BricsCAD LicenseLevel including the optionally licensed components (Communicator, SheetMetal, Bim);
"RunAsLevel" setting is respected in result list;

returns a list like
("CLASSIC" "PROFESSIONAL" "PLATINUM" "COMMUNICATOR" "SHEETMETAL" "BIM")

depending on license level and "RunAsLevel", particular items will be present or not
(items are always uppercase, "CLASSIC" is always present)

I hope this should simplify the license & components detection :-)
many greetings !

Vaidas Guogis

 Great, thank you, Torsten!

Roy Klein Gebbinck

@Jason:
My test shows that the LICFLAGS variable changes in accordance with the RUNASLEVEL variable (after restarting BC). So there is no need to check the latter. Thanks again for the 'smlispget' and 'getcfg' info.
For V14-V16:
[code](defun BricsCADLicenseLevels ( / flags vernum)
  (if (= "BRICSCAD" (strcase (getvar 'product)))
    (progn
      (setq vernum (atoi (getvar '_vernum)))
      (setq flags (getvar 'licflags))
      (vl-remove
        nil
        (list
          "CLASSIC"
          (if (= 2 (logand flags 2)) "PRO")
          (if (= 4 (logand flags 4)) "PLATINUM")
          (if
            (and
              (= 4 (logand flags 4))
              (or
                (<= 14 vernum 15)
                (and (<= 16 vernum) (smlispget "CheckSheetMetalLicense"))
              )
            )
            "SHEETMETAL"
          )
          (if
            (and
              (= 4 (logand flags 4))
              (or
                (<= 15 vernum 16)
                (and (<= 17 vernum) (getcfg "SkpStitch"))
              )
            )
            "BIM"
          )
        )
      )
    )
  )
)[/code]

Roy Klein Gebbinck

@Torsten:
Thanks for that new function. Since it can be emulated (see my attempt and Jason's code) it is worth considering using the 'vle-' prefix for the function name. Extending the LICFLAGS to include those 'Verticals' may also be a good idea.

Torsten Moses

Dear Roy,

when using "vle-" function family, that code would need emulation for AutoCAD (and other CADs) ...
but those "PRO", "PLATINUM" and especially "BIM", "SHEETMETAL" etc. license stati would not make sense under AutoCAD - it would even more trigger to run particular, BricsCAD-only code ...

In generally, all the "smXxxx", "bmXxx" etc. commands are only available with BricsCAD, so I think, it would not really help to provide such license stati under AutoCAD :-)

many greetings !

Roy Klein Gebbinck

@Torsten:
Of course the function name is not a big issue and I understand your argument, but there are already 'vle-' functions that are meaningless when used outside BricsCAD (vle-start-transaction for example). Also not all 'vle-' function are emulated (vle-write-int64 for example). So the 'vle-' naming convention is not very strict.  In this case the emulated function could simply return nil (see product check in my code).

Torsten Moses

Dear Roy,

thanks for your feedback, as usually :-)

There is nevertheless an important difference :
the emulated (vle-start-transaction) is indeed a No-Operation under other CAD systems ...
BUT
it will not have a functional difference, so Lisp code will continue "as is", without differences.

For the license function here, it is more complicate, as it effectively will influence functionality ...
it might return (list "CLASSIC" "PROFESSIONAL") under AutoCAD, as that would be a comparable level ...
likely I will also add the license function as "vle" prefixed version :-)

For the special vle-read/write functions you are right ... such cases should remain the exception
(was added for a particular developer ...)

many greetings !

Jason Bourhill

@Roy Klein Gebbinck:

'Guessing' how a user wants to insert a drawing may prove to be impossible:
1. In case of a 'normal' dwg use Insert or Xref (attach or overlay)?
2. What if a user has a BIM license but wants to use BmInsert in a particular case?
3. A 'static' component can also be BmInserted/BimInserted.

I have the same questions myself. Currently you need to use multiple different, but similar commands, to trigger different, but similar actions. I think it's preferable to use the same command to trigger different actions depending on what you insert. Annotative & Dynamic blocks are an example of this. Their type is set in their definition, they don't need different commands to insert them. After insertion you can see from their properties what type of insert they are.

In V17, when you create a BIMINSERT, or BMINSERT you can set the 'Extension type' from the Mechanical Browser. This option wasn't present in V16. I infer from this that, in the future, you may be able to use the INSERT command to achieve the same outcome. Note that blocks created in V16 won't have their 'Extension type', so you wouldn't be able to rely on this setting alone. I guess you could infer type by inspection. A BMINSERT component should of been initialised with BMMECH, so have a component name. A BIMINSERT will typically also contain the BIM_Subtract layer.


Regards,

Jason Bourhill

CAD Concepts

Roy Klein Gebbinck

@Torsten:
Thanks again. Introducing a separate prefix for functions that cannot be emulated is perhaps a good idea?
VLE=Emulated.
VLB=BricsCAD only.

Roy Klein Gebbinck

@Jason:
Currently I have 8 potential insert actions on my list:

1. Normal Insert
2. Normal Insert + Redefine
3. Xref Attach + Absolute path
4. Xref Attach + Relative path
5. Xref Overlay + Absolute path
6. Xref Overlay + Relative path
7. BmInsert
8. BimInsert

Notes:
A.
In V17 you can no longer rely on the BIM_Subtract layer. All solids (except on BIM_UNITE/BC_UNITE layers) will be subtracted if the component is BimInserted.
B.
BIM drawings can also have an 'Assembly Context'. A BimInsert action seems to automatically create it. But strangely the BimInsert command fails if called directly after BmMech (at least in V16).
C.
A component that has become an anonymous block (BimInsert or BmInsert+Modified parameter) can potentially be inserted with the normal Insert or Xref commands.
D.
Analyzing drawings with ODBX can be time-consuming (and problematic if the drawing has been opened by a different user).

Most likely I will do something like this:

1. If the drawing matches an existing component (BmLispGet) use BimInsert or BmInsert depending on license levels.
2. If the drawing matches an existing xref use the Xref command.
3. If the drawing matches an existing block use the Insert command.
4. Else rely on user input (perhaps store setting per folder?).
   

Jason Bourhill

(BCAD$LicenseLevels) is now available in V17.1.19

(car (member "CLASSIC" (BCAD$LicenseLevels)))
"CLASSIC"

Regards,
Jason Bourhill
CAD Concepts

Roy Klein Gebbinck

The BKG_Browser application is now available. Freeware.