Getting what the length would be if "Auto" in the FabricationAPI

[cyan]

Just doing a little QA/QC routine and I want to write something that determines if some duct is longer than what it would be if it were set to "Auto".

I feel a bit disappointed because I've tried a lot of stuff and this is oddly not coming together, even though it feels like it should be simple.

Code: [Select]

    public static double? GetAutoLength(this Item item)
    {
        var lengthDim = item.GetDimension("Length");
        if (lengthDim is not ItemComboDimension lengthComboDim) return null;
        if (lengthComboDim.SelectedOption == "Auto") return lengthDim.Value;

        return GetSpecBasedAutoLength();
    }

GetSpecBasedAutoLength is what I'm trying to write and can provide examples for, but they're all way too ugly for my taste.

I've tried doing a lot of crazy stuff to try to get at what the value for "Auto" would eventually be, including crawling the spec tables and I've tried briefly setting the item's length to "Auto", updating, getting the resulting double, and setting it back.

The latter actually worked but it is quite the hack and I'm not a very big fan of that, although it did highlight to me that I'll need to build out something as a sort of transaction system. So maybe I'll work on that first.

Anyway, if anyone has insights on this, would be appreciated. It'll be run many times during one of my operations, so the hacks that I've produced are not really the answer. Hoping for something that I just didn't see past the dev blinders.

[cyan]

It's not ideal but I have a solution that works for the specific case I'm in, but still needs maturing.

Code: [Select]

        var item = mapper.From<Item>(lineItem);
        if (item.CID != 866) yield break;
        var autoLength = item.GetAutoLength();
        if (autoLength.IsSuccess) yield break;

        var materialWidth = item.GetMaterialWidth(true);
        var connectorAllowance = item.GetConnectorAllowance();
        var length = item.GetDimensionValue("length");

        if (materialWidth.IsError || connectorAllowance.IsError || length.IsError) yield break;

        var netLength = materialWidth - connectorAllowance;
        if (Math.Abs(length - netLength) > MinimumDifference) yield break;

Obviously this is not flat code and there's a lot to work through here. It is trying to determine if the piece was drawn close enough to what would be "Auto", it should just be set to that for the decoiler.

The FabAPI uses a lot of traversing and casting and stuff. So I put extensions and an `Outcome` return type to use that I have in my NuGet package. This helps to define the happy path while also doing .. something at least.. for the many things that can go wrong during traversal.

Example

Code: [Select]

    public static Outcome<double> GetAutoLength(this Item item)
    {
        var lengthDim = item.GetDimension("length");
        if (lengthDim.IsError) return lengthDim.Error;
        if (lengthDim.Value is not ItemComboDimension lengthComboDim) return new Error("No length combo box dimension");
        if (lengthComboDim.SelectedOption != "Auto") return new Error("Length dimension was not set to auto.");
        return lengthComboDim.Value;
    }
So if you get a success result out of this, it literally means that "Auto" was selected and so the value is the true auto value. And there's no need to process it. That's why on success, it just yields a break result.

Now GetMaterialWidth is the one I have issue with

Code: [Select]

    public static Outcome<double> GetMaterialWidth(this Item item, bool addBuffer = false)
    {
        var length = item.Gauge is not MachineGauge machineGauge
            ? null
            : machineGauge.FlatBedSizes.FirstOrDefault()?.Width;
        if (length is null) return new Error("Could not get a material width from the gauge.");
        const double buffer = 0.125;
        return addBuffer ? (double)length + buffer : (double)length;
    }

I was able to get the flatbed size of the material, both width and length. But if you look at your materials in the UI database, there's a Slit Coil Width in the table and that is where I want the real value from. But I just put in an optional overload for now that gives me the 1/8" that I need on top of the width so I can do a calculation using the total of the connector turnovers too.

I just don't like writing things into my code that are copies of information that are correct at the time of writing code. I wanna get it from where it actually lives. But whatever. It's working.

Let me know if you have any questions about this, there's obviously a lot more going on.

[craigjonnson]

I use a similar process.... (Its in Metric) and not as in-depth as what you are trying to achieve.

Code: [Select]

select item.cid
case 866
   if item.dim[3].numvalue >= 1395 and item.dim[3].numvalue <= 1450 then
      item.dim[3].value = "Auto"
      item.dim[3].locked = false
   end if
item.update()
end select

[cyan]

Yeah, there's a script we run that does essentially what you have there.

Since this is a method in an API app, I'm hoping to build something that assumes less and *could* be used for other straight types in the future too. Round duct, piping, whatever.

[DotNet]

Here are my thoughts…

I've tried doing a lot of crazy stuff to try to get at what the value for "Auto" would eventually be, including crawling the spec tables and I've tried briefly setting the item's length to "Auto", updating, getting the resulting double, and setting it back.

The latter actually worked but it is quite the hack and I'm not a very big fan of that, although it did highlight to me that I'll need to build out something as a sort of transaction system. So maybe I'll work on that first.

There is nothing wrong with this. It is the path of least resistance, and likely the most accurate. It’s is how I have been doing it, and is a standard practice for AutoCAD API stuff in general. Knowing the turnovers and material width is also very useful and applicable here.

If we’re talking about a coil line, I would ignore any straights that have connectors that don’t match, or that have connectors that we don’t typically run through our coil line. Those are for the plasma table anyway.

[cyan]

There is nothing wrong with this. It is the path of least resistance, and likely the most accurate. It’s is how I have been doing it, and is a standard practice for AutoCAD API stuff in general. Knowing the turnovers and material width is also very useful and applicable here.

As I wrote that, the funny thing is that I thought you, specifically, were going to roll your eyes at it. So this response was very validating, thank you.

I think my chief concern outside of some ethereal "Well it just doesn't feel right, bro", is that I am concerned about side effects. I don't want to perform manipulations on the data that was curated by detailing or the shop that weren't intentional. In this case, it's investigative. In my mind, if a bunch of stuff broke because I temporarily changed the part, I did not want to have to answer for that. It would sound pretty bad, you have to admit. I hope that makes sense.

But if there's precedent for it, and it really hasn't had that problem, that is highly useful information.

[DotNet]

I think my chief concern outside of some ethereal "Well it just doesn't feel right, bro", is that I am concerned about side effects. I don't want to perform manipulations on the data that was curated by detailing or the shop that weren't intentional. In this case, it's investigative. In my mind, if a bunch of stuff broke because I temporarily changed the part, I did not want to have to answer for that. It would sound pretty bad, you have to admit. I hope that makes sense.

Your software engineering experience and intuition is serving you well here. You were absolutely right to be concerned, and you were right to start thinking about a transaction wrapper object. Wrap the AutoCAD ProgressMeter too and add it to your transaction wrapper. Create multiple constructors and options. Have fun with it…

Our main goal in this example is to acquire the data without modifying the document.

Option 1
Start a transaction, make changes, acquire data, abort. The document is not altered in any way.

Option 2
Start a subtransaction within a transaction, make changes, commit the subtransaction, acquire data, abort the transaction. The document is not altered in any way.

Option 3
Ideally, we never want to change a value, commit a transaction, acquire data, and then commit a separate transaction to reverse the change. This is a valid last resort, however. The Fabrication API can be a real pain in the ass sometimes.

[cyan]

That's the rub. The target user will be in CAMduct, since it is a shop inputter QA/QC tool. I haven't given it an exhaustive glance, but I do not know of anything resembling a transaction being available in the Fab API. We can do it upstream, even in Revit, but it's really something the inputters should catch.

[DotNet]

Switching hats here… All MEP contractors are facing this problem in one way or another, whether they are using fabrication, or not.

Every solution has its own distinctions, however every solution needs a tolerance. Simply reporting or scheduling every straight that is not set to “auto” will quickly become overwhelming. Short joints are not necessarily a bad thing and are extremely common. That I think we can all agree on. IMO - tiny tolerances are for the shop and/or scripts to deal with. Anything else is a coordination/VDC issue, and needs to be delt with accordingly.

Crag’s solution works well and is how many contractors are dealing with it. If the straight in question is within some tolerance of standard, make it standard and be done with it.

● Coil duct focused.
● Valid connectors and materials only. Everything else is for the plasma table.
● Standard length is hard coded and varies for each connector and material type combination.
● Tolerance is hard coded and can also vary for each connector and material type combination.
● Generally, a very low tolerance does not need to be re-coordinated.
● Higher tolerances can lead to issues as this will move our joint locations and tie in points significantly, causing a domino effect. AKA - Generally not good for anything welded or precision.

Just doing a little QA/QC routine and I want to write something that determines if some duct is longer than what it would be if it were set to "Auto".

I'm hoping to build something that assumes less and *could* be used for other straight types in the future too. Round duct, piping, whatever.

That’s a great idea. I implemented it in Revit years ago. It works with any straight given the database is configured properly.

● Standard length is computed at runtime for each individual straight.
● Tolerance is adjustable.
● Works with any pipe, duct, or electrical straight.
● Works with any spec, connector or material type.
● Does not burden the user with providing, guessing at, or thinking about any of this information.
● Optionally flags/colors/schedules/zooms to relevant straights for evaluation and/or coordination without overwhelming the user with false positives.

The concept is straight forward. Any straight with Length >= Computed Standard - Tolerance is optionally flagged/colored/scheduled/zoomed for evaluation. The math inherently covers any oversized straights. A zero tolerance will report all non standard straights.

Using a single selected TDC/TDC straight for example…

● User defined tolerance = 4”.
● Standard length computed at runtime = 56”
● If length >= 52” – it’s flagged.

It helps QA/QC lots of other stuff too. SMACNA standards, minimum length, ptrap drops, sloped risers, inverted straights, disconnections, missing part numbers, invalid materials...

Anyone is welcome to try it.

[cyan]

When I'm implementing the QA/QC process in Revit, I think I will be feeling much more flexible in the approach to all of this. Since we're trying to allow inputters to do what inputters do within the environment best fits their purpose, I was essentially stuck with finding a way to make CAMduct handle it.

For now, I've handled rectangular duct by having a procedure that does these things (best I can recall since I wrote it)
- Get the current stretchout of the item by adding the length of the duct and the connector turnovers.
- Compare this to the width of the material that it will be cut from if decoiled.
- Are the values within that tolerance?

From here, the question is how to present it to the user. There's some history to this. What the inputters had before I started this was a lot of scripts that "just took care of it". This is good in some ways, but it does not enable them to grow in the role or take ownership of the process. I wanted to give the "easiness" of the scripts and also enable the users.

So instead of automatically fixing anything, on opening the AddIn, they are presented with a list of items that have suggested adjustments. They come in varying urgency levels like "Suggestion, Warning, Critical", much like a log system.

But it actually tells them, item by item, what the rule was that was flagged. Why it was flagged. And what the system will do to fix it, or what they can do to fix it.

For the moment, I was able to make it fix everything for them just by mass selecting and saying "Send it". But the key here is that they have the choice to stop, evaluate, and learn through the utility what the rules are that we support. JetBrains Rider literally did this for me and my code hygiene in C#. It's so cool when the software is not just an easy button but also a coach.

I'm also having an eye toward marking some of these rules as being enforceable in the detailing department. Then providing the rulesets via NuGet so the Fab and Revit AddIn are both pulling and using literally the same rules. But just abstracting the API dependent code behind dependency injection.

[DotNet]

From here, the question is how to present it to the user. There's some history to this. What the inputters had before I started this was a lot of scripts that "just took care of it". This is good in some ways, but it does not enable them to grow in the role or take ownership of the process. I wanted to give the "easiness" of the scripts and also enable the users.

So instead of automatically fixing anything, on opening the AddIn, they are presented with a list of items that have suggested adjustments. They come in varying urgency levels like "Suggestion, Warning, Critical", much like a log system.

But it actually tells them, item by item, what the rule was that was flagged. Why it was flagged. And what the system will do to fix it, or what they can do to fix it.

Very nice. We also do this with a parameter. Multiple issues can be flagged and described within. Since parameters are native to Revit, users can tag, schedule, and filter views and schedules based on specific QC issues.

When I'm implementing the QA/QC process in Revit, I think I will be feeling much more flexible in the approach to all of this. Since we're trying to allow inputters to do what inputters do within the environment best fits their purpose, I was essentially stuck with finding a way to make CAMduct handle it.

I know the feeling. We have to reinvent the wheel for CAM/EST only API solutions. There isn't even native selection support. It's Windows 98 era software. In my experience CAMduct guys usually have access to CADmep and enjoy using it when required. I always push for tools like these to be done in CADmep whenever possible. The AutoCAD API props CAM/EST up significantly, for us, and for them.