服务项目 |
LabVIEW软件 |
面向地区 |
全国 |
LabVIEW作为图形化编程语言，近几年发展迅速，它具备开发快、可靠性高等特点，非常适合测控领域的应用。
在该领域我们已经有十几年的开发经验，合作用户涉及科研、、外企、大中小型各类企业。服务领域遍布自动测控系统众多领域，包括航空航天、汽车产品测试、工业自动化、故障诊断、图像处理等。
"术业有专攻"，每个人都有自己擅长的领域。把这些工作交给我们，使您有精力做科研，这应该是一个双赢的局面。借助我们在LabVIEW十多年的经验，为用户提供更、更的技术服务
很多人在问LabVIEW 该怎么学才能快速速写出好的程序？除了多练习外没有速成的方法。但是想要靠写LabVIEW 讨生活？哪有那么简单。
1. 事前准备：
a. 了解 LabVIEW 常用基本功能。所谓 " 工欲善其事，必先利其器 " ，现在网上的资料也很多，找起来很方便的。。很多人留言或来信问问题，许多连基本概念都不清楚，跟他说了这个问题，还是不知道该怎么做或为什么那样做
b. 搞清楚资料格式： LabVIEW 是资料导向的程序，资料格式不一样就有可能出现不同的结果。大家尽量多看英文原版的说明，学了那么久的英语，为什么用上呢。
c. 杂学知识：有用到时多少要先了解一下，至少要有一定的概念。
其他程序语言 (C 或 VB… 等 ) ：不要求精，但起码要看的懂程序码。除非你不做仪器控制，否则多少都会接触到。就目前接触过的仪器设备，其仪器设备的函数手册或通讯手册范例很多是用 VB 等其他程序语言写的，若看不懂那要如何去改写成 LabVIEW 程序
PLC ：对被控制的对象总要有一定程度的了解，如 PLC 的阶梯图程序，硬体的 IO 接点、内部接点和外接模组，还有通讯格式之类的资料。没有一定的基础往往出了问题却不知道要从哪里下手
图像处理：图像处理的基本原理和色彩转换 … 等知识
数据库：不管用的是哪种资料库，SQL 的语法是一定要会的。
2. 资料流的观念：
上面说过的 " LabVIEW 是资料导向的程序 " ，资料跑到哪里程序就执行到哪里。程序是可以同时跑多条资料流程，但若是多条资料流程会用到同一个变数，就有必要把执行的先后顺序厘清，确定资料的流向。打个比喻来说：资料流就像单行道，可以有多条单行道通向某处，但出口只有一个，那会是哪台车先通过出口呢？这时当然是设定红绿灯来控制先后顺序
3. 程序注解：
程序注解是有必要的，因为大一点的程序往往是分给几个人去写，加上程序注解比较好沟通，同时了解这段程序在整个程序中的作用。主要也是避免一段时间后，自己也看不懂当初写的程序
4. 程序整理：
很多人的程序，说实在看到画面重叠和那一团左右交错的线条就很头大。干净的画面有助于了解程序，在监看模式时更容易了解资料的流向。写的时候多花点时间，后面调试修改的时候就会节省很多时间。所谓磨刀不误砍柴工。
5. 程序细节：
a.能拉直线的就尽量不要转弯，线条的转折越少越好
b.线能拉的到的就不要使用 local 之类的变数，没必要时尽量不要使用 local 之类的变数
c.太多资料要传递又不想拉太多线，那就把资料用 Array 或 cluster 打包成一条线
d. 顺序结构要谨慎使用，执行顺序不固定时就不要用。有要随时停止的程序也尽量不要用顺序结构，顺序结构往往是不能立即停止的元凶，必需使用时一定要安排好能跳过顺序的条件，例如改用Case取代顺序结构
e先求功能再求精简：复杂一点的程序不可能一次搞定都没有问题，这时是把需求功能先做出来，测试到没问题后，再研究程序哪边可以再精简
f.善用错误代码除错：较复杂的程序几乎都不可能一次搞定，在测试时会跳出各种各样的的错误信息，可以从错误信息去找出问题的所在。若是觉得错误信息不够详细，可以用错误代码的数字查询详细内容。方法是：点选下拉式功能表Help底下的Explain Error那一项，在Code输入错误代码并且点选Status按钮将其变为红色的X，这样一来错误代码的描述就会出现在Explanation里了
6. 程序分段书写测试：
一个大程序不可能一次搞定，一些片段或重复部份可以先分开写，测试到没有问题后再打包成 SubVI 整合进去，后续也可以掉出来重复使用 许多仪器控制适用这种方法，先测试和仪器通讯到没有问题，在将测试程序打包成 SubVI 整合到主程序内
7做SubVI有几个要项：
1. SubVI输入加输出资料合计能用的接点有限，考虑到未来要扩充功能的需要，输出输入点数的总和尽量控制在12～16点之内，若要超出这个限制有些接点就需使用Cluster或array
2.SubVI之中还可以包含其他的SubVI，数量不限
3.输入点尽量安排在左边，输出点尽量安排在右边。资料输出入有相关连的SubVI，同类型的资料接点要安排在相对应位置
当然，如果项目很着急，或者自己公司缺少LabVIEW的工程师，可以联系外包，比如我们公司
LabVIEW程序学习建议（具体可登录www.bjcyck.com）:
labVIEW学习开发出一个程序，非常简单，拉几条线放几个Funtion，很快就能够完成了，但是，你有考虑过你的程序内存使用问题吗?、有考虑过其他人接手(或是下次你再复习)容不容易阅读?、又或是程序架构扩增的弹性呢?
NI Example :
我推荐初学者再遇到不会的function、或有时间的时候将NI Example打开来看看一样的功能Example怎么写出出来的，然后模仿再写一次，这样反复练习才会学习到比较好的good style。NI在文件上面非常的下功夫，教学的资源也是非常的多，每次的LabVIEW升版都能看到新的Example，也会淘汰一些不范例程序。
Help-->Find Example
或是对着组件按Control+H ，在内文中找Find Example
2.LabVIEW 书籍 :
这里有两本书推荐，
一本是比较适合初阶，CLD程度阅读的LabVIEW For Everyone，这本是本英文书，深入浅出的介绍LabVIEW的组件，
另外一本市圣经，The LabVIEW Style Book，这本书我之前有介绍过，可以参考: LabVIEW_推荐参考书_The LabVIEW Style Book， 这本书分成很多段落在分享和教导读者如何建立程序架构、设计亲切易懂的人机接口和养成良好习惯 。
3.论坛:LabVIEW Pro、NI英文论坛
网络上很多LabVIEW资源，从以前的LabVIEW360、LAVA、LabVIEW Pro，我都很建议可以去浏览，这编列几个:
LabVIEW Pro : 小编很用心地在经营，有练功区、程序基础教学、讨论区、技术专题..等
NI Discussion Forums : 外国搞手讨论都辉激起如元子弹的震撼教育
LabVIEW 360 : 很多不错的资源，讨论人气也是非常的旺
LAVA : 讨论很多VI扩充tools
如果项目着急或者需要外包，推荐www.bjcyck.com。他们从事LabVIEW开发十几年，可以联系咨询。
程序写作建议:
1. 使用英文版的LabVIEW:
LabVIEW许多资源都是用英文的，包括白皮书、使用说明、Help文件、或是spec文件..等等。用英文版的LabVIEW开发熟习组件名称，这样再搜寻资源会比较轻松；放心，英文接口对写程序不会有什么影响的。
2.LabVIEW Good Style :
使用Good Style开发LabVIEW是我一再强调的，好的写作习惯养成是日后建立大型项目的重要基础，要检查自己的程序是否符合Good Style简单也是快的方法就是打开Analyzer。
Tools-->VI Analyzer-->Analyze VI
他分析的面向很广包括:Block Diagram、Complexity Metrics、Documents、Front Panel、General、VI Metrix
分析完后会给一份报告，评估程序的风险程度，可以看到自己写出来的程序哪边和建议的违和，
或是直接查看 LabVIEW Check List ，检查什么事重要的项目。
5.架构选择:
我觉得程序架构只要稳、易维护，都是很好的架构；所以我并没有非常推崇高阶的程序项目架构，我认为需要依照项目、团队来选择程序架构，不过如果是初学者学习的话，我推荐下面的程序架构:
State Machine :适合小程序，需要轮转重复的功能
Producer & Consumer: LabVIEWPro介绍中文版
Queue Message Handler :这个比较进阶一点，不过试LabVIEW的Project Template，教学文件很多，可以试试看
Template-->Producer/Consumer
Template-->Simple State Machine
6.程序整理
程序凌乱会降低Coding效率，意大利面程序、会增加维护的困难。
1. 建议常常使用工具把整理程序
2.避免过多弯取的线、堆栈的线
7.Type Define
使用State Machie Enum、GUI Tab、交握的Data、传递在不同程序的Data...等常常再不I或是同一个VI使用多次的原件都将型态存起来，好处是修改时不用一个一个更改，使用Type Define后一次可以修改到全部。
可以参考这篇教学:https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019MFtSAM
8. 程序大小控制在同一个画面中
如果你的撰写需要用50吋的屏幕才能完整展开，是需要整理得程序、利用SubVI、好的程序架构、Good Style，增加程序阅读性。
9.不要滥用global、local Variable
变量滥用、Race Condition是LabVIEW开发初期的通病，使用过多会造成程序的不稳定性。试着使用FGV、Shit Register来取代这些跳脱数据流概念的变数；
这篇有详细的介绍: LabVIEW_什么是Race Condition(竞争危害)?
10 程序批注
千万不要觉得批注是帮助别人阅读自己的程序才需要写，我的经验是，大部分都是帮助自己 不用一年，程序逻辑没有文件的辅助是很难快速切入的。
应该是LabVIEW2014后，批注还可以加上箭头，非常的方便。
11.使用Cluster
Cluster的使用可以简化Block Diagram，重要的是可以让相关的资料做一个结合，在后续的使用上比较清楚，也减少connect的接角。
请注意，当在bundle 和unbundle cluster 时一定要使用by Name的方法，好搭配type define做cluster的数据结构定义。
12.开始写做前规划程序架构、应用方式
开始撰写前先想过程序需求用什么架构来开发会更融易、把需求想过一次后，会看到很多一开始想不到的盲点。好是画出流程图，并把这些开发文件都留在项目、程序的文件夹中，帮助日后的阅读。
程序人机(GUI)建议:
1.利用对齐工具来让面板整齐:有各种对齐、置中对齐、靠左对齐、靠右对齐...
2.利用调整间距工具: 有各种调整间距的方法:平分、固定间距、0间距...
3.调整对象大小: 调整对象大小，也可以多选多个对象将他们调整成大小全部一样。
4.字体大小\颜色:
整个面板的字体大小、颜色好控制在3种不同的组合，过多颜色、大小会让画面过于凌乱。可以分成 不重要小字(size:14、灰色)、正文(size:16、黑色)、非常强调(size:20、红色)
5.利用Tab简化控制组件很多的人机，才不会让使用者一次看到过多的控制组件产生恐惧感(?)
可以参考NI Example-->Programmatically Manipulate a Tab Control.vi 来看使用方法
Debug程序建议:
利用Explain Help查看错误码，每个错误都要发挥侦探的精神，找出实质的原因，才不会出现"幽灵bug"的问题。(有时候会发生有时候又不会发生的bug)
项目程序建议:
1.文件夹整理，将程序依照自己的固定方法、分类整理control、SubVI，这样在移动项目时，不容易有"丢包"的subVI，也容易一目了然项目的程序用途。
2.使用VI Hirechy检视
从hirechy可以检查程序的整洁度和关联图，在阅读他人的程序格外重要，可以从这个架构途中，了解整个项目架构和应用层面。
如果项目着急或者需要外包，推荐。他们从事LabVIEW开发十几年，可以联系咨询。
最近来访记录
