首页 文章 精选 留言 我的

精选列表

搜索[不可见索引],共10000篇文章
优秀的个人博客,低调大师

图框可见性问题专篇:PNG看不到图框,到底是bug还是机制?

> 一个让无数人以为“技能坏了”的坑,其实只是图纸空间和模型空间的区别 ## 一、先讲一个让所有人第一次都懵掉的场景 你用WorkBuddy生成了一个DXF施工图,导出PNG预览一看——图上只有线条和标注,**没有A3图框,没有标题栏**。 你第一反应:技能坏了。 于是你重新生成一遍,还是没图框。再生成一遍,依然没图框。你开始怀疑是不是图框生成那一步根本没执行。 **但如果你用CAD软件打开同一个DXF文件,切换到布局标签页,图框和标题栏就出现了。** 这不是bug,是DXF的工作机制。 ## 二、根因:模型空间和图纸空间,是两个世界 DXF文件里有两个独立的空间: |空间|英文|放什么|PNG预览看得到吗| | --- | --- | --- | --- | |**模型空间**|Model Space|图形本体(墙体、门窗、标注)|✅ 看得到| |**图纸空间**|Paper Space|图框、标题栏、视口|❌ 默认看不到| **国标A3图框是放在图纸空间的**,因为图框是“排版层”的东西,不是“图形本体”。PNG导出工具默认只渲染模型空间,所以图框不显示。 用一个比喻:模型空间是画在纸上的图,图纸空间是装这张纸的相框。PNG只拍了画,没拍相框。但相框一直都在,只是没进镜头。 ## 三、怎么验证图框确实生成了 三个方法,按方便程度排序: **方法一:用CAD软件打开,切换布局标签** 用任意CAD软件(AutoCAD、中望CAD、甚至免费的DWG TrueView)打开DXF文件。窗口底部会看到标签页:一个叫`Model`,一个叫`GB_A3`(或类似名称)。 点`GB_A3`标签,图框和标题栏就出现了。 **方法二:让WorkBuddy列出布局信息** 在对话框里说: > 读取这个DXF文件,列出所有的布局(Layout)名称,以及每个布局里包含的实体类型和数量。 如果输出里显示有一个叫`GB_A3`的布局,里面有`BORDER`图层、`TITLE`图层,说明图框生成成功了。 **方法三:导出图纸空间的PDF** 在WorkBuddy里说: > 把这个DXF文件的GB_A3布局导出为PDF。 PDF会包含图框和标题栏。这是最接近“最终交付效果”的预览方式。 ## 四、交付时怎么避免这个坑 ### 如果你是自己用 记住一句话:**PNG看图形,CAD看排版。** 需要检查图框时,用CAD打开切布局。 ### 如果你是交付给客户/同事 在交付说明里写清楚: > DXF文件包含两个空间:模型空间存放图形本体,图纸空间存放国标A3图框和标题栏。用CAD软件打开后,切换到`GB_A3`布局标签页即可看到完整图框。PNG预览图仅展示模型空间内容,不含图框。 这一句话能省掉对方发来的“你的图框呢?”。 ### 如果你要出一份带图框的预览图 让WorkBuddy把图纸空间导出为PDF,而不是PNG。PDF会完整保留图框和标题栏。 > 把这个DXF文件的GB_A3布局导出为PDF,保存到指定目录。 PDF可以直接发给客户看,不需要对方装CAD。 ## 五、一个容易混淆的点:为什么有些图框能看到? 你可能会发现,有些DXF的图框在PNG里能看到,有些看不到。 区别在于**图框画在哪个空间**: |图框位置|PNG能看到吗|常见于| | --- | --- | --- | |模型空间|✅ 能看到|简易出图、非标准流程| |图纸空间|❌ 看不到|国标出图、正规流程| 国标制图规范要求图框放在图纸空间,所以**正规出图的图框,PNG默认都看不到**。能看到图框的,反而是没按规范来的。 ## 六、一句话总结 **PNG看不到图框,不是图框没生成,是PNG只拍了模型空间。** 验证方法:用CAD打开切布局标签。交付方法:附一句说明,或者导出PDF代替PNG。 这个坑不解决,你会一直以为技能坏了;解决了,你会发现它从来就没坏过。 --- > 操作环境:WorkBuddy桌面客户端 + Python 3.9 + ezdxf 1.4.4,所有示例均已在本地验证通过。 > 本文为“DXF工程线”避坑短篇,适合在遇到“图框消失”问题时快速查阅。

优秀的个人博客,低调大师

Elasticsearch压缩索引——lucene倒排索引本质是列存储+使用嵌套文档可以大幅度提高压缩率

注意:由于是重复数据,词法不具有通用性!文章价值不大! 摘自:https://segmentfault.com/a/1190000002695169 Doc Values 会压缩存储重复的内容。给定这样一个简单的 mapping mappings = { 'testdata': { '_source': {'enabled': False}, '_all': {'enabled': False}, 'properties': { 'name': { 'type': 'string', 'index': 'no', 'store': False, 'dynamic': 'strict', 'fielddata': {'format': 'doc_values'} } } } } 插入100万行随机的重复值 words = ['hello', 'world', 'there', 'here'] def read_test_data_in_batches(): batch = [] for i in range(10000 * 100): if i % 50000 == 0: print(i) if len(batch) > 10000: yield batch batch = [] batch.append({ '_index': 'wentao-test-doc-values', '_type': 'testdata', '_source': {'name': random.choice(words)} }) print(i) yield batch 磁盘占用是 size: 28.5Mi (28.5Mi) docs: 1,000,000 (1,000,000) 把每个word搞长一些,同样是插入100万行 words = ['hello' * 100, 'world' * 100, 'there' * 100, 'here' * 100] def read_test_data_in_batches(): batch = [] for i in range(10000 * 100): if i % 50000 == 0: print(i) if len(batch) > 10000: yield batch batch = [] batch.append({ '_index': 'wentao-test-doc-values', '_type': 'testdata', '_source': {'name': random.choice(words)} }) print(i) yield batch 磁盘占用不升反降 size: 14.4Mi (14.4Mi) docs: 1,000,000 (1,000,000) 这说明了lucene在底层用列式存储这些字符串的时候是做了压缩的。这个要是在某个商业列式数据库里,就这么点优化都是要大书特书的dictionary encoding优化云云。 Nested Document 实验表明把一堆小文档打包成一个大文档的nested document可以压缩存储空间。把前面的mapping改成这样: mappings = { 'testdata': { '_source': {'enabled': False}, '_all': {'enabled': False}, 'properties': { 'children': { 'type': 'nested', 'properties': { 'name': { 'type': 'string', 'index': 'no', 'store': False, 'dynamic': 'strict', 'fielddata': {'format': 'doc_values'} } } } } } } 还是插入100万行,但是每一千行打包成一个大文档 words = ['hello', 'world', 'there', 'here'] def read_test_data_in_batches(): batch = [] for i in range(10000 * 100): if i % 50000 == 0: print(i) if len(batch) > 1000: yield [{ '_index': 'wentao-test-doc-values2', '_type': 'testdata', '_source': {'children': batch} }] batch = [] batch.append({'name': random.choice(words)}) print(i) yield [{ '_index': 'wentao-test-doc-values2', '_type': 'testdata', '_source': {'children': batch} }] 磁盘占用是 size: 2.47Mi (2.47Mi) docs: 1,001,000 (1,001,000) 文档数没有变小,但是磁盘空间仅仅占用了2.47M。这个应该受益于lucene内部对于嵌套文档的存储优化。 本文转自张昺华-sky博客园博客,原文链接:http://www.cnblogs.com/bonelee/p/6269604.html,如需转载请自行联系原作者

优秀的个人博客,低调大师

T536 + FPGA这通信速率,大家觉得还行不

大家好,我是发际线守护者。在当今工业数字化高速发展的时代,异构通信技术的重要性不言而喻。屏幕前的你,是否正因为ARM与FPGA交互方案的带宽不足、数据吞吐能力受限苦恼不已? ## **▍**认识PCIe PCIe是一种高速串行计算机扩展总线标准,旨在大幅提升计算机系统的总线吞吐量与设备间的通信速率。本方案采用“RC-EP”架构: (1)**Root Complex(RC,根复合体):**全志T536承担主机角色。主要负责PCIe链路的初始化、设备的枚举与配置,并作为主控方主动发起数据交互。 (2)**Endpoint(EP,端点设备):**由FPGA实现PCIe Endpoint逻辑。作为从设备响应RC的读写访问请求,配合完成高效的数据传输(如PCIe DMA)。 ## **▍**PCIe DMA VS CPU DMA DMA即直接内存访问,使用DMA方式进行数据传输时,外设可以直接与内存进行数据交换。减少了CPU的介入和中断处理,数据传输过程更加流畅和高效。本方案分别用到了两种DMA方式: (1)**PCIe DMA:**PCIe控制器内置DMA,作为总线主控直接通过PCIe链路读写主机内存,效率极高,适用于大数据量交互。 (2)**CPU DMA:**利用ARM内部的系统DMA控制器实现,主要用于管理SoC内部外设与内存之间的数据搬运。 ![](https://developer.qcloudimg.com/http-save/8546319/df7cd748aa05bac4d15ea8d90efa1138.png) ## **▍**实测数据对比 以下基于创龙科技T536工业评估板进行演示。执行测试程序,将随机数据先写入FPGA BRAM,再从FPGA BRAM读出,测试完成后,程序将打印读写平均传输耗时、读写平均传输速率、读写错误统计等信息。 通过PCIe DMA传输: ![](https://developer.qcloudimg.com/http-save/8546319/f2332913100d3d2cd5e1d91032369264.png) 通过CPU DMA传输: ![](https://developer.qcloudimg.com/http-save/8546319/9e87363f29f5762580b6b322646c861e.png) 无DMA传输: ![](https://developer.qcloudimg.com/http-save/8546319/e374328d5980cdfb64bfce3b2d1617c2.png) 基于PCIe总线传输的读写带宽汇总如下: ![](https://developer.qcloudimg.com/http-save/8546319/487fe48780ff6f5e82963f04bb0c1a15.png)

优秀的个人博客,低调大师

不写代码也能开发?Node-RED带你飞

大家好,我是发际线守护者,一名坚守**「一般情况不加班」**原则的软件工程师。相信多年深耕工控开发的兄弟应该都深有体会:传统开发方案的代码开发门槛高,固件程序灵活性差,固化了就难修改,设备功能扩展又受限。这导致不仅开发繁琐,还严重拖慢项目落地和迭代进度,头发又有继续掉落风险! 有没有这么一个方案,既不用花大量时间编写复杂代码,又不用反复编译固件,让头发少掉点,保护我们珍贵的发际线呢?这里我推荐一个方案:**Node-RED + ARM工控机**,它凭借拖拽式可视化编程,随时可调,灵活性高的特点,打破传统开发壁垒,大幅降低了工控开发的门槛,并能加快工业现场开发和进行灵活迭代。 ![图1](https://developer.qcloudimg.com/http-save/8546319/c05e398a77e5068eaa92adb659173897.jpg) # **▍**为什么选择Node-RED? **代码少门槛低:**拖拽式可视化编程,无需复杂代码,新手也能快速上手开发。 **现场调试便捷:**支持现场实时修改逻辑、调整程序,适配多变的工业现场。 **扩展升级灵活:**海量节点插件,轻松实现功能迭代、设备扩展,适配多场景工控需求。 # **▍Node-RED案例演示** 以工业现场最常见的温湿度数据采集为例,我们使用创龙科技RK3576工控机与温湿度变送器,基于Node-RED工具,实现温湿度传感器数据采集与可视化监控功能。将温湿度变送器连接至ARM工控机RS-485接口,硬件连接框图如下所示: ![图2](https://developer.qcloudimg.com/http-save/8546319/65fcd3a8a232401f1cd189770d5ea5f3.jpg) 工控机运行Node-RED,通过PC机的浏览器进入对应链接,打开Node-RED编辑器进行程序开发(可参考产品资料开发手册安装、配置节点插件)。 节点位于编辑器左侧,选中节点后,可直接拖拽至编辑器画面中间(即流程界面),双击节点可进行配置。编辑完成后点击右上角部署按键,将案例部署到工控机。 ![图3](https://developer.qcloudimg.com/http-save/8546319/3e774028330f1b04313c4e28d681cc87.png) 通过PC机的浏览器进入对应链接,打开UI界面。点击启停开关,即可开始/暂停获取温湿度传感器的数据,并能观察运行状态(对应控制硬件LED1状态)。 ![图4](https://developer.qcloudimg.com/http-save/8546319/95c24dd3ebfd2539dec952f7bc99a609.png) 由上方案例可看出:Node-RED + ARM工控机的开发方案,操作便捷、部署简易,是工控开发更方便快捷的选择。 在**ARM工控机**的选择上,创龙科技有多款国产现成整机可选配,覆盖**多网口、多串口、多DI/DO**等机型,采用“单板机” + “扩展板”产品形态,单板机处理器型号(RK3588/RK3576/RK3562/T153...)和扩展板(多网口/多串口/多DIDO...)均可随意更换。扩展板**原理图/PCB全部开源**,可自行快速修改,做到灵活拓展,开箱即用。 ![图5](https://developer.qcloudimg.com/http-save/8546319/b8ede73124c47807c3eaa7ea98162f20.jpg) ![图6](https://developer.qcloudimg.com/http-save/8546319/4236fdffb8200e485963179ce2894510.jpg)

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册