【翻译】使用CCF创建设备驱动程序

​1976年，Blue OysterCult乐队发布了他们的热门歌曲《Don't Fear the Reaper》。2000年,周六《夜现场》制作了一个虚构的幽默小品，围绕着《不要害怕死神》产生过程的,叫《更多的牛铃》。《MoreCowbell》这出小品为这首热门歌曲的制作增添了轻松愉快的气氛。看了那部小品后，我再也无法用同样的感觉听那首歌了。牛铃是一个很小的乐器，但在这首歌里却占了非常重要的一部分。

在半导体制造工具中使用的硬件也是如此。机台控制归结为对硬件的控制。如果不控制硬件，如果Robot不移动，用户界面和工厂自动化就没有多大意义。从Robot到Load Port上的一个简单的状态传感器，一切都是被需要的。看似最简单的设备却可能是最突出的。每个设备在这个过程中都扮演着重要的角色。

Cimetrix在2016年3月15日发布了一篇题为《CIMControlFramework工作分解》的博客文章，文中将驱动程序集成确定为CIMControlFramework(CCF)应用程序工作分解中需要完成的第一步。创建一个驱动程序来控制硬件似乎有些令人生畏。需要连接到设备。有一些需要处理的命令和可能的响应。这可能是压倒性的，但是可以通过理解需要做什么来控制设备去克服他。

让我们看看如何着手开发一个驱动程序。

1. 使用所有可用的文档了解设备的接口。这些文档将提供关于如何发送命令和解释响应的信息。

a.  这个设备是控制一个还是多个设备？

b.  跟这个设备通讯的通讯协议是什么？

       i.     TCP/IP

       ii.    串口

c.  有哪些命令？命令是怎么组成的？

d.  有哪些响应？

e.  会需要轮询设备吗？

f.  设备有可能主动发送信息吗？

2. 了解需要对机台上的设备做什么控制。

您只需要使用接口的一个子集还是整个接口?如果只是一个子集，那么一开始就只需要写那些。

3. 编写代码与设备“对话”。

 a.     你有这个设备的模拟器吗?

这一点很重要，特别是在硬件可用性有限的情况下。如果需要，可以开发一个简单的模拟器，至少验证通信，然后随着时间的推移进行扩展，以模拟故障或其他情况。当机台开始组合在一起，那么，当开发机台的其他部分以及协调各个设备时，每个模拟器都变得非常有价值。

 b.     单元测试，对于在实际硬件上使用之前，验证驱动程序的行为是否符合预期是很有用的。单元测试还可以在对驱动程序进行更改时提供回归测试。考虑单元测试的一些领域：

    i.       连接失败的处理;

    ii.      向设备发送失败或从设备接收失败的处理；

    iii.     返回值的处理。

c.   从简单的开始，只要连接设备即可。接下来发送一个简单的命令并查看响应。创造成功，在成功的基础上再接再厉!

最后，驱动程序将发送命令并获取和解释响应。为每一个设备创建一个驱动程序，你也会成为该设备的专家。

尽管开始可能有些令人紧张，但开发驱动程序是工具开发中有趣的部分之一。没有什么比看到硬件开始按照软件中精心设计的方式跳舞更令人兴奋的了。

CCF提供了实用程序和示例来帮助创建硬件驱动程序并轻松地将它们集成到应用程序中，以帮助您在工具控制中编排和提供更多的cowbell。

要了解更多关于CCF的信息，请访问我们网站上的CIMControlFramework页面!

  

Create Device Drivers Using CCF

 

In 1976, Blue Oyster Cult released their hit song, “Don’t Fear the Reaper”.  In 2000, Saturday Night Live produced a fictitious, but humorous skit around the production of the “Don’t Fear the Reaper” called, “More Cowbell”.  The “More Cowbell” skit put a very light hearted spin on the production of the hit song. After seeing that skit, I can never hear that song the same way. The cowbell, for as small a piece it plays, is a huge part of the song.

 

 

The same can be said for the hardware that is used in Semiconductor manufacturing tools.  Tool control boils down to controlling the hardware. Without controlling the hardware, the UI and factory automation will not amount to much if the robot doesn’t move. Everything from the robot, down to a simple presence sensor on a load port is needed. What may seem to be the simplest device can be the most prominent. Each device plays an important part in the process.

A Cimetrix blog post on March 15, 2016 entitled CIMControlFramework Work Breakdown, identifies driver integration as one of the first steps that needs to be done in the work breakdown for a CIMControlFramework (CCF) application. It may seem intimidating to create a driver to control hardware. There is the need to connect to the device. There is some number of commands and possible responses to deal with.  It can be overwhelming, but can be conquered by understanding what needs to be done to control a device through a driver.

Let’s look at how to go about developing a driver.

1.  Understand the interface to the device using any and all documentation available.  The documentation will provide information on how to send commands and interpret the responses.

a.  Does the device control only one device or many?

b.  What is the communication protocol to the device?

i. TCP/IP

ii.Serial ports

c.  What are the commands?  How are the commands composed?

d.  What are the responses?

e.  Will the device need to be polled?

f.  Will the device send unsolicited messages?

2.  Understand what needs to be controlled on the device for the tool.

a.  Will you only need to use a subset of the interface or the entirety of the interface?  If just a subset, then there is only a need to write those initially.

3.  Writing code to “talk” to the device

a.  Do you have a simulator for the device?

This one is important, especially if the hardware has limited availability.  If needed, a simple simulator can be developed to at least validate communications, then expanded over time to simulate faults or other conditions.

As the tool begins to come together, each simulator will become invaluable when developing the other parts of the tool and coordinating the devices together.

b.  Unit tests can be useful to verify that the driver behaves as expected before using on actual hardware. Unit tests can also provide regression testing should changes be made to a driver. Some areas to consider unit testing;

i. Handling of failure to connect

ii.Handling of failure to send to the device or receive from the device

iii.    Handling of return values

c.  Start out simple, just get a connection to the device to begin with. Next send a simple command and inspect the response.  Create a success and build upon the successes!

In the end, a driver will be sending commands and getting and interpreting a response. For every device you create a driver for you’ll also become the expert on that device.

Even though it can be intimidating to start, developing driversis one of the fun parts of tool development. There is nothing more exciting than seeing the hardware begin to dance in the fashion that has been choreographed in your software.

CCF provides utilities and examples to help create drivers for your hardware and easily integrate them into the application, to assist you to orchestrate and provide more cowbell in your tool control.

To learn more about CCF, visit the CIMControlFrameworkpageon our website!

Topics: Equipment Control-Software Products, Cimetrix Products 

Posted by Tim Hutchison: Senior Software Engineer on Dec 6, 2016 11:30:00 AM