All Activity

"Thanks for confirming. That completely locks in my decision to statically link SQLite into the BRX—it's clearly the only safe way forward to avoid process space conflicts. DuckDB and Arrow are powerful, but definitely overkill for a parametric generator framework. Keeping it clean with zero external DLL dependencies is the way to go."

In real time? I think is saw one for like $300 will post later tonight.

An external application? Wich one? Is there any software available that can do this?

In a recent Tuesday Tips, I focused on some solutions for the poor drafting practice of not having your annotations in alignment. This time, the focus will be on overlapping objects and annotations. The drafting rule is quite simple: don’t overlap things. But as we learned from that pirate movie franchise, sometimes rules are more guidelines than actual rules. By that, I mean that there are times when overlaps are just unavoidable. However, there are some tools in AutoCAD that let you hide objects in these cluttered areas. AutoCAD wipeouts and text masking are the focus of today’s Tuesday Tip. Wipeout Consider the image below. Having the line appear behind the pneumatic gate valve symbol is a big no-no. These days, programs such as Plant 3D take care of this for you, but if you’re using an old-fashioned symbol library, your only option is to trim out the line within the block. Not an optimal solution. Instead, we’ll add a Wipeout object to the block definition. In the next image, you’ll see the valve block open in the Block Editor, and we can find the Wipeout tool in the Markup panel of the Annotation tab. It’s incredibly easy to use; if you can draw a polyline, you can create a Wipeout. Select points and enter close to end it, or you can choose an existing polyline (then erase it or not), In our case, we want the wipeout to take on the same shape as the valve symbol, or a “bowtie” shape. Using an Endpoint Osnap, select the corners of the valve in the order shown. Save the edited block, and return to the drawing editor. If you’re following along at home, the red lines are probably not hidden. If the block already exists, as it does in our example, you may need to change the draw order of the newly edited block. Select all instances (a good use of Select Similar, or Quick Select), then right-click, expand Draw Order, and select Bring to Front. Your wipeout should now hide the red line behind it. Wipeouts come with an additional control you’ll need to know about. There is a system variable that controls how the frame, or outline, of the wipeout works. The variable is WIPEOUTFRAME, and you can set it to 0, 1, or 2, which correspond to: 0: The frame is not visible, and it is not plotted. The frame temporarily reappears during selection preview or object selection. 1: Displays and plots the frame. 2: Displays, but does not plot the frame. A lot of underlay image objects have their own setting (such as PDFFRAME), and the FRAME command itself controls all of them. Sounds confusing, doesn’t it? Don’t worry, I’ve got you covered. I wrote about it a few years ago. Just go here (after you finish this blog) to learn all about it. Text Masking A close cousin to Wipeouts are Background Masks. Think of them as specialized wipeouts that work only with MTEXT objects. Consider the image below. The drawing contains a detail callout block with an MTEXT object identifying the area as Detail C. Its placement falls on top of the objects above it. It’s poor drafting to say the least. Again, I’ll edit the block via the Block Editor. I’ll double-click on the MTEXT as if I’m going to edit it (which I am). The Ribbon will switch to the contextual Text Editor tab, where I’ll click on the Mask tool from within the Style panel. You’ll immediately be presented with the Background Mask dialog. It’s pretty simple. There’s a checkbox to use a mask or not. That’s why I’m here, so I’ll make sure it’s selected. I don’t want a special color for the mask (are you trying to call attention to your text? Perhaps you’ll want to set a color). We want our mask to be effectively invisible, so I’ll select the Use drawing background color checkbox. If I left it unchecked, I could select my color from the widget on the lower right side. When you’re done, save the block, and you should see the mask applied to the block’s text as shown in the image below. In the example, there’s some extra space above and below the text. That’s the offset factor that you saw in the mask dialog. A Few Final Thoughts In both examples, I added the Wipeout and Text Mask to existing blocks. Obviously, they work straight from the drawing editor as well, and you’ll probably never encounter the Draw Order issue – at least at the time of their creation. And yes, I know, the examples were a bit flawed as well. I alluded to that with the valve symbol. I doubt if any serious piping designer would be using such old-school blocks, but it helped drive home the point. And, what about the Detail C symbol block? Making the text into an attribute and adding a dynamic Move action would be a better way to manage the block. But thanks for sticking with me! Of course, you should make every effort to use good drafting techniques. If at all possible, you should avoid these object overlaps whenever you can. But when it’s not possible, these masking tools can help you keep your drawing clean. More Tuesday Tips Check out our whole Tuesday Tips series for ideas on how to make AutoCAD work for you. The post Cleaning Up the Clutter with AutoCAD Wipeout and Text Masking: Tuesday Tips With Frank appeared first on AutoCAD Blog. View the full article

Yeah, my thought would be to use an external app to talk to the receiver, save the coordinates to a text file somewhere continuously - probably by overwriting a simple text file 'X-Coord Y-Coord Z-Coord Description' - same format all the time - all done outside of CAD. Have CAD running and using a delay (https://forums.autodesk.com/t5/visual-lisp-autolisp-and-general/using-delay-command-in-scripts/td-p/5497881 for an example) get CAD to read this file as necessary, plot the point

Your trying to talk to an external device, something that Autocad was never really designed to do out of the box.. Other than say a Digitiser. Yes in survey software including CIV3D there are programs that talk to survey instruments, but some one has writen say a .NET interface to do the talking part. So you need a external program Python may do it for you, Lisp is a pretty low level language when it comes to interfaces. You need functions that do that and they are probably not built into the Lisp interpreter. Bricscad has added lisp functions to its software they are not available to say Acad as improvements. In the case of mobile phone photos I used a 3rd part program to read the details from the jpg images so could get the lat and long and insert in a dwg at correct location. Using lisp could call the other external program. look at Startapp can call a bat file. "Need a thread" then why not talk to hand held distance measures, I am sure others would come up with other devices also that they would like plug and play.

SqliteLisp’s only dependency is the BRX SDK. I compiled SQLite as a static library so it can be truly embedded. it’s not hard to extract the parts you need, along with the SQLite source to create a BRX. You’re correct in that you would need to build for every BricsCAD version you intend to ship with. If you have an external program also using SQLite, it’s likely you will need two instances, one for your program, one for BricsCAD. Even though they might be compiled differently, reading the database file is guaranteed. Here’s the problem using a SQLIte as a .DLL, BricsCAD already uses a customized version of SQLite internally, that means you cannot use another version within BricsCAD’s process space, you’re forced to use BricsCAD’s and you don’t know what they have changed or what extensions they have enabled. You’ll have no control on the BricsCAD side. That's why static embedded in a BRX is better, you can load in your own instance, compiled with your own flags. Another option is to use DuckDB, it may be possible to build a .DLL interface for lisp and your external program. DuckDB is incredibly fast with certain storage methods, DuckDB also supports Apache Arrow, next generation high performance embedded database.

Thanks for the example, BIGAL! Nested/child DCLs (like the one in image_4483c9.png) are a great, proven way to handle multi-level configurations without cluttering the main screen. Regarding Excel as a database—you're absolutely right that 99% of users know how to use it, and using a text file for user-defined layers is an excellent way to keep things flexible. However, for a complex parametric generator, I heavily lean towards SQLite over Excel for a few critical reasons: Performance & Overhead: Reading/writing heavy datasets via COM (vlax-get-or-create-object) creates noticeable lag, especially when querying "zillions" of hardware parameters in real-time. SQLite executes queries in milliseconds completely in-memory or via a tiny local file. Zero Dependencies: Using Excel via ActiveX means the user must have Microsoft Excel installed. If they use LibreOffice, Google Sheets, or a different CAD platform setup, the COM links break or require entirely different codebases (as you mentioned having separate LibreOffice code). SQLite runs natively inside the LISP environment without caring what office suite is installed. Stability: We've all experienced ghost EXCEL.EXE processes hanging in the Windows Task Manager when a LISP routine crashes or fails to unallocate the object properly. SQLite avoids that entirely. That being said, I am planning an "Export to Excel/CSV" feature for BOMs (Bill of Materials) and cutting lists, because as you perfectly pointed out, Excel is the universal language for production managers and workshop staff! Thanks for the snippet and the food for thought! Zen

Thanks for the replies. It seems that, despite the passage of time, this is still a very rarely discussed topic. I have only found one very old thread dealing with this issue, but it approaches it from VBA and does not appear to reach a solution: https://forums.autodesk.com/t5/autocad-map-3d-developer-forum/reading-gps-output-on-a-serial-port-with-vba/td-p/624634&ved=2ahUKEwif9v7MqpqVAxWuHDQIHXXNAncQFnoECCQQAQ&usg=AOvVaw2qjyYBboSx0JnXyKbmPsbU⁠� I suppose this is not something that is easy to achieve from Lisp. I’m not sure I fully understand the @BIGAL idea of using an external program: do you mean a program that does all the work from outside AutoCAD? (I may not have understood correctly.) Thanks, @Danielm103. I’ve never used Python with AutoCAD before. Perhaps this is the right time to start doing so I really think this topic deserves a thread that finally results in the solution that nobody has managed to find so far.

Nice work my friend. I will add Y - Sorted to String and i think it more easily to use ^^

I could be wrong only glanced at code. (if (and (>= l_ang (* pi 0.5)) (< l_ang (* pi 1.5))) (setq i_ang (- l_ang pi) d_pt (polar m_pt (- i_ang (* pi 0.5)) (* tht 0.3))) (setq d_pt (polar m_pt (- i_ang (* pi 0.5)) (* tht 0.3))) );end_if ; needs a another if here (If (= ?????) (rh:em_txt m_pt a_txt b_lyr i_ang tht 1 1) (rh:em_txt d_pt l_txt d_lyr i_ang tht 1 3) );end_if Or do you need a (progn so can add in more lines to the IF is true. maybe this I don't know. Not sure about i_ang and l_ang. (if (and (>= l_ang (* pi 0.5)) (< l_ang (* pi 1.5))) (progn (setq i_ang (- l_ang pi) d_pt (polar m_pt (- i_ang (* pi 0.5)) (* tht 0.3))) (rh:em_txt m_pt a_txt b_lyr i_ang tht 1 1) ) (progn (setq d_pt (polar m_pt (- i_ang (* pi 0.5)) (* tht 0.3))) (rh:em_txt d_pt l_txt d_lyr i_ang tht 1 3) ) );end_if

This is just a simple example of the way you can use child dcl's to set values as your hinting about sheet thickness, material etc. Obviously it would match your requirements. Maybe even a 2nd child, pick size -> Pick outside material -> laminate plastic none etc. Using some form of data base sounds like a good idea, we had a text file for the layer names used in the code so a user could set up their preferred layer naming not ours. Have you though about using Excel as the info database ? You can read and write to Excel, have the Excel displayed or just behind the scenes read the Excel without a visual display. Note LT2024+ does not support Excel link. Works with Bricscad not tested with Intellicad but I think should work. There are a couple of other CAD programs as well. The nice thing about Excel is that 99% of people know how to use it. Obviously there is so much help about making macros for Excel if needed. In case you don't have it a simple test for Intellicad. ;; Try to get or create Excel instance (setq myxl (vl-catch-all-apply 'vlax-get-or-create-object '("Excel.Application"))) Ps yes have Libre Office code as well.

Thankyou with the quick responses. Apologies for my late reply. I had a play with the code from "mhupp" and using: (defun rh:em_mtxt (pt txt lyr ang hgt) (entmakex (list '(0 . "MTEXT") '(100 . "AcDbEntity") '(100 . "AcDbMText") (cons 8 lyr) (cons 50 ang) (cons 7 (getvar 'TEXTSTYLE)) (cons 1 txt) (cons 10 pt) (cons 40 hgt) (cons 50 ang) '(71 . 5) ) ) );end_defun Gives the error: no function definition: RH:EM_TXT occurred Makes sense because I need to add "(rh:em_mtxt '(0 0 0) "71" "0" 0 0.5)" After which it seems to run the routine with no errors but also no text displayed? I have uploaded a sample drawing using the original Lisp to annotate the linework. Thanks again for your help I feel like something is wrong here on line 107: (rh:em_txt m_pt a_txt b_lyr i_ang tht 1 1) (rh:em_txt d_pt l_txt d_lyr i_ang tht 1 3) );end_repeat ) );end_cond ...and that I'm not implementing (rh:em_mtxt '(0 0 0) "71" "0" 0 0.5) properly Annotate Sample.dwg

Hi Daniel (Its_Alive) and everyone in this thread, I have been analyzing this project thoroughly, and the architectural concept behind your SQLiteLsp extension is brilliant. Having a dedicated BRX module with an embedded SQLite engine that exposes clean AutoLISP functions like (DSQL_OPEN), (DSQL_ASSOCQUERY), and (DSQL_CLOSE) is exactly how professional data-driven CAD/CAM applications should be built. However, after running a deep compatibility check for our current enterprise furniture design engine (project ZEN PRACA V2B34), we hit a classic deployment bottleneck. The original module was compiled for BricsCAD V12 around 2011. Even looking at later iterations for IntelliCAD, relying on a pre-compiled binary extension (.brx / .irx) creates a heavy production risk regarding x64 architecture alignment, modern compiler library dependencies, and strict binary compatibility with newer host CAD versions. Because we are currently stabilizing our central parametric engine, we have made a strategic decision not to plug the old V12 BRX module as a production dependency right now. Introducing an external binary at this critical stage could create a second "source of truth" and lead to dependency hell, distracting us from core geometric validation. That being said, the SQLite philosophy is absolutely a GO for our next development phase, but as a clean data persistence layer structured into a strict three-tier architecture: Data Layer (SQLite): To store externalized project profiles, global cabinet variables (PARAMETRY_SZAF), construction tolerances (PROFILE_KORPUSU), zoning maps (MODULE_MAP), internal equipment payloads (shelves, rods, drawers), and manufacturing logs (BUILD_MANIFEST, BOM). SQLite is the perfect serverless, file-based standard for this, especially with the engine being actively developed (up to version 3.53.2 in mid-2026). Logic Layer (Central LISP Engine): Our pure AutoLISP core that reads these parameters, validates manufacturing constraints, and calculates the exact spatial coordinate plans. Presentation Layer (DWG): The clean, visual 3D output generated by a fully controlled and audited geometry builder. Our Roadmap: We are first finalizing the central engine and rule registry using native, structured LISP association lists (which perfectly mimic the flat row-and-column layout of a relational database). Once the geometry is 100% robust, we plan to write a lean, modern SQLite adapter tailored specifically for our V2B34 schema, completely free of legacy binary dependencies. Thank you for this thread—it completely validated our choice to move towards a relational database structure for complex parametric wood-engineering projects! Best regards, Zen

Did you have a look at this? SQLite for AutoLisp https://www.theswamp.org/index.php?topic=28286.0 I haven't updated it in a while though

That is exactly why I ended up developing a custom SQLite implementation for AutoLisp! Managing the zillions of parameters required for dynamic cabinetry and hardware logic became impossible with standard lists or light dictionaries. SQLite handles it like a breeze. I used that database to automatically select the correct drawer hardware based on dimensions. Back then, both Grass and Blum sent me their complete block libraries, which allowed the system to automatically drop those components into detailed section views. It’s a shame I didn't back up absolutely everything from that setup, but the core architectural logic is what I'm reviving now. Building it as an integrated package from day one—just like you mentioned—is the only way to survive a project of this scale!

hanks for sharing your experience! Hearing that your system took 12 months confirms that building a solid foundation from day one is the only right way. I completely agree on using common naming conventions and a master library—it's the only way to keep the codebase maintainable and scalable. Also, thank you for the tip on Ldata. I am definitely steering clear of USER variables to avoid any conflicts with other plugins or user setups. Ldata is exactly what I'm utilizing to keep the drawing data clean and robust. Much appreciated! Zeno

Also, this work was the whole reason I made SQLite for Autolisp, to handle the zillions of parameters. Could automatically select the correct drawer hardware, I only had Grass and Blum though, they both sent me all the blocks too so I could use them in sections, I should have saved all that stuff

I think you’ll get into trouble with the way your parameters are laid out. Example, the user may not have access to vertical grade laminate, or may wish to use cabinet liner, or just melamine. These thickness changes will have a big impact. You will need parameters for the possible, inside, inside finished, outside, outside finished T_SIDE, the left might have a finished end while the right might not. MAT_OUTSIDE_FINISHED + T_LEFT_SIDE + MAT_OUTSIDE_UNFINISHED Edging is another item, i.e. 0.5mm vs 3mm banding will affect the overall depth

I personally do not need any software, as Cabinets etc are not in my usual skill set, but keep working on it. Just a comment the house package that I worked on took 12 months to develop. We worked out from day one had to have an integrated package with every module having links to master defuns. Using common variable names throughout code then others can add to code. In one of your other posts you have hinted that is the way you are approaching the task which is good. If you need to save values in the dwg avoid the USER?? variables. I use Ldata it seems to work well.

AI really is helpful but often takes re.ques. Without having been so inspired and learning from y'all, I would have no language to com with. One recent review wow for me is HATCHB.lsp. Without it (JTB) ..I'd Not be able to get a hatch boundary period.

ow yeah, I disabled all notifications in my profile. Too many people assumed I have nothing else to do so I got a lot of personal requests this way and though I love to help other humans it soon became a full time job and consumed all of my spare time. I'll send you my adres.

I think you would need Python, .NET, or ObjectARX as Autolisp does not have an on idle event that I can see. According to AI, you can read the input stream in a background thread, then use AutoCAD’s on idle event to update geometry in AutoCAD. I asked AI about using PyRx and it spit out a bunch of code converting $GPGGA $GNGGA to Lat/Log and stuff, I attached it. scratch.txt

hank you for your interest. Yes — kitchen cabinets and other furniture types are planned as future directions for the project. The current work is focused on a lightweight parametric CAD/CAM engine for fast rebuilding of furniture layouts after changes from an architect or client. The goal is not to create heavy 3D models with every fitting fully modelled. Instead, the system is intended to control construction, dimensions, divisions, fronts, drawers, shelves, fitting rules, and automatic updates of layouts, sections and dimensions. For kitchens, the direction would be similar: base units, wall units, tall units, fronts, drawers, shelves, plinths, fillers and technical fitting rules. The main benefit is that after another design change, you do not need to redraw the entire project from scratch or manually check whether all drawings still match the model. We have posted early concept boards of the parameter panel and engine workflow here on the forum. Since publishing them, we have already received useful feedback and implemented some corrections. The long-term goal is for the solution to work not only in BricsCAD, but also in AutoCAD. Please send me a private message with the type of kitchen or furniture workflow you are interested in and what you would expect from such a system. It would be useful to compare requirements and continue the discussion there.

What about kitchen cupboards do you have those as well ? Indicative cost ?