Engineers Turn to Automated Test Equipment to Save Time

With engineers rushing tests in order to hit tight product deadlines, the market for test equipment that automatically detects faults in semiconductors and other components is growing.
Setting aside time for testing has been a struggle for electrical engineers. The shrinking size - and increasing complexity - of semiconductor circuits is not making life any easier. Nearly 15% of wireless engineers are outsourcing final testing and more than 45% contract manufacturing – when most semiconductor testing takes place.
Almost 65% of the survey respondents said that testing is still a challenge in terms of time consumption. New chips designed for tiny connected sensors and autonomous cars also require rigorous testing to ensure reliability.
Tight deadlines for delivering new products is forcing engineers toward using automated test equipment, also known as ATE, to quickly identify defects in semiconductors, especially those used in smartphones, communication devices, and consumer electronics.
The global automated test equipment market is estimated to reach $4.36 billion in 2018, up from $3.54 billion in 2011, according to Transparency Market Research, a technology research firm.
Automated test equipment is used extensively in semiconductor manufacturing, where integrated circuits on a silicon chip must be tested before it is prepared for packaging. It cuts down on the time it takes to test more complex chips, which are incorporating higher speeds, performance, and pin counts. Automatic testing also helps to locate flaws in system-on-chips, or SoCs, which often contain analog, mixed-signal, and wireless parts on the same silicon chip.

Exploiting LabVIEW Libraries

Have you ever viewed a LabVIEW VI Hierarchy and become frustrated with not being able to locate a VI you needed to open?
Do you have large applications composed of similar modules but fear to jump, with both feet, into the learning curve of LVOOP?
Did you ever try to duplicate a sub-VI at the start of a new set of functions and find yourself deep in a nest of cross-linked VIs, or save a VI only to realize that the most suitable name has already been used?
Then using LabVIEW Libraries may be useful to you
Libraries are a feature available in the LabVIEW project or they can be created stand-alone*. They have a number of features that allow you to specify shared properties and attributes of related VIs and custom controls.
In short, many of the features of LVOOP are available without the complications required for Dynamic Dispatching. The remainder of this document will serve as a tutorial that demonstrates how to create, define, and clone a library. Additional notes are included to illustrate how these features can be exploited to help you develop more robust applications that are easier to support than applications that do not use libraries.
*Libraries can be created stand-alone from the LabVIEW splash screen using the method:
File >>> New … >>> Other Files >>> Library
You can create a new library from the project by right-clicking the “My Computer” icon and selecting “New >>> Library”. Save it to a unique folder that will contain all of the files associated with the library.
Open the properties screen and then open the icon editor) to compose a Common Icon for the library and its members.
Take a little time to create the icon because it will be shared by all of the members of the library. Do not get carried away and fill-up the entire icon. Leave some white space so that the icons of the component VIs can be customized to illustrate their role in the functionality of the library.
Create virtual folders in the library to help organize the VIs contained in it. I usually use three folders but you can use more or less depending on your needs and preferences. I use one to hold the controls, and another pair for the public and private VIs. I do not use auto-populating folders for a number of reasons.
I can control which VIs are included and which are not. Occasionally temporary VIs are created to do some basic testing and they are never intended to be part of the library. If functionality changes and the temporary VI breaks due to the change, the library may cause a build to fail due to the broken VI.
I can easily move a VI from private to public without having to move the VI on disk and then properly updating source code control to reflect the change.
I can keep the file paths shorter using the virtual folders while maintaining the structure of the project.
Additional virtual folders can be added if you want to further break-down the organization of the VIs in the library. If developing a library that will be used by other developers and or be as a tool for others, you may want to include a folder for the VIs that define the API your library offers. The API can also be divided into additional virtual folders to break-down the interface into functional areas if you wish. Implement the Logical Grouping of sub-VIs as needed for your library.
Set the Access Scope of the private virtual folder to private. While the private folder and the setting of the access scope can be optional, taking advantage of this options will help you and the users of your library identify which VIs are not intended for use outside of the library. Attempting to use a VI with a private scope from outside the library itself will break the calling VI and make it very obvious that the VI is not intended for public use.
Developing applications using libraries differs little from developing without libraries with one exception; there is no additional work to use them. The exception is illustrated in Figure 8 where the name of the VI is highlighted. While the VI named in the project is shown as “Init_AI.vi” the actual name of the VI is “DAQ.lvib:AI.lvlib:Init_AI.vi”. The difference is the result of what is called “Name Mangling”. The actual name of the VI is prefixed by the library names that own the VI. This is a powerful feature that goes a long way toward avoiding cross-linking and will let us easily clone a library to be used as the starting point of a similar library.
The Save as the screen for the library will not only let us define the library name but also where in the project the library will be placed. This is handy for nested libraries but not critical. The libraries can be moved around in the project or between libraries as need using the project window. When a library is cloned using the Save As an option, all of the VIs contained in the original library are duplicated and re-linked to the VIs in the new library. There is NO chance of cross-linking when Cloning a library!
Libraries can help in all phases of an application from initial development to long-term support through to knowledge transfer. Remember, “Libraries” are your friend!

LabVIEW Improvements

LabVIEW passed its 30 year anniversary in 2016,  and six months ago, National Instruments, has launched a considerably updated version of LabVIEW - its Next Generation LabVIEW NXG 1.0.
LabVIEW NXG is a totally reworked version of LabVIEW and this enables it to offer a considerably improved level of performance. By adopting an approach where LabVIEW has been started again from the ground up, LabVIEW NXG enables users to see significant improvements in performance as a result of the new code.
LabVIEW NXG offers some significant definitive improvements over the previous implementation of LabVIEW:

• Plug & Play: a lot of work has gone into enabling LabVIEW NXG to provide easy set-up of hardware connections. It has true plug and play functionality.
• IDE: The LabVIEW NXG environment has been totally overhauled to take elements of popular commercial software and replicate the attributes of the environment to make it more intuitive.
• Tutorials: To facilitate the speedy uptake of newcomers to LabVIEW, the new LabVIEW NXG has inbuilt walk-throughs and other integrated learning facilities. This has been shown to greatly speed up the time which it takes for newcomers to be able to proficiently programme in LabVIEW. It is even possible to undertake a number of standard tasks without “hitting the code.”

National Instruments will be running both the traditional LabVIEW, i.e. LabVIEW 2017 which has also been launched alongside the new next-generation LabVIEW NXG, but ultimately when total compatibility has been established the two will converge enabling users to benefit from the new streamlined core.
Users of LabVIEW will be given access to both LabVIEW 2017 and later versions as well as LabVIEW NXG. In this way, they can make the choice of which version suits their application best.
National Instruments spokespeople stressed that the traditional development line of LabVIEW will continue to be maintained so that the large investment in software and applications that users have is not at risk. However, drivers and many other areas are already compatible with both lines.

“Thirty years ago, we released the original version of LabVIEW, designed to help engineers automate their measurement systems without having to learn the esoterica of traditional programming languages. LabVIEW was the ‘nonprogramming’ way to automate a measurement system,” said Jeff Kodosky, NI co-founder and business and technology fellow, known as the ‘Father of LabVIEW.’
“For a long time, we focused on making additional things possible with LabVIEW, rather than furthering the goal of helping engineers automate measurements quickly and easily. Now we are squarely addressing this with the introduction of LabVIEW NXG, which we designed from the ground up to embrace a streamlined workflow. Common applications can use a simple configuration-based approach, while more complex applications can use the full open-ended graphical programming capability of the LabVIEW language, G.”

IoT: Security and Privacy

Two key IoT issues, which are also intertwined, are security and privacy: the data IoT devices store and work with needs to be safe from hackers, so as not to have sensitive data exposed to third parties. It is of utmost importance that IoT devices be secure from vulnerabilities and private so that users would feel safe in their surroundings and trust that their data shall not be exposed or worse, sold through illegal channels. Also, since devices are becoming more and more integrated into our everyday lives (many people store their credentials on their devices, for example), poorly secured devices can serve as entry points for cyber-attacks and leave data unprotected.

 

The nature of IoT devices means that every unsecured or inadequately secured devices pose a potential threat. This security problem is even deeper since various devices can connect to each other automatically, thus refraining the user from knowing at first glance whether a security issue exists. Therefore, developers and users of IoT devices have an obligation to make sure that no other devices come in any potential harm, so they constantly develop and test security solutions for these challenges.

 

The second key issue, privacy, is thought to be a factor which holds back the full development and implementation of IoT. Many users are concerned about their rights when it comes to their data being tracked, collected and analyzed. IoT also raises concerns regarding the potential threat of being tracked, the inability of discarding certain data collection, surveillance etc. Strategies need to be implemented which, although bring innovation, still respect user privacy choices and expectations. In order for Internet of Things to truly be accepted, these challenges need to be looked into and these problems need to be overcome, which is a great task and a test both for developers and for users.

Requirements of real time control

Real time embedded control processors are individual computing units which have been implemented into pieces of larger and far more complicated equipment such as vehicles of all sort (trucks, airplanes, boats, yachts etc.), then other computer peripherals, audio systems and military equipment and weapons. The control processors are said to be embedded because they are integrated into a piece of equipment which is not in itself considered a computer nor does it execute some computing functions.

Requirements of real time control

Whether they are invisible or visible to the user, the real-time control processors are nowadays widespread and incorporated into people’s daily life and actions. For example, an invisible real-time control processor can be found in vehicles: this is the ABS (automatic braking system) which holds the vehicle steady on the road and prevents it from skidding on the road. Also, a real-time control processor can be used to replace high cost, high maintenance and bulky components of a given system, while at the same time providing better functions at a lower expense. In other certain occurrences, the presence of a real-time control processor may be visible, for example, an autopilot on an aircraft. But in all aforementioned cases, this real-time control processor is still a part of a larger system. And because of the fact that it is a component of a greater system, and that system has its own requirements and operating capabilities, most of these systems limit the processor in regard to its size, then weight, cost, power or reliability. Simultaneously though, the real-time control processor is bound to deliver top performance, for these real time events are mostly external inputs to the system which is in need of a response within milliseconds. If the processor fails to deliver a response in such short time span, disaster may strike: the autopilot may not change the course of the aircraft accordingly and may misinform the pilot about altitude.

About Temperature Data Loggers

A data logger is, simply put, an electronic device which records and stores data. There are various ways data devices, or data loggers, tools designed for recording or monitoring processes and different parameters, acquire data. These data loggers have become a revolutionary solution for logging vast amounts of data and are nowadays symbolized by a vast array of devices, from small, handheld ones to complex systems. For example, a data logger device can be applied to automobile and other vehicle control, then the acquisition of machine or engine data and monitoring of conditions present in a machine. Multichannel systems which track vibration, force detection and various measurements in turbines and generators can all be found. The findings are later presented as charts, graphs and diagrams.

Temperature data logger

Temperature data loggers, also called temperature monitoring devices, can be found with ease, and they offer a variety of solutions to adapt to any temperature measurement scenario. Data loggers which measure atmospheric temperature almost always have a built-in sensor which is then employed to measure surrounding temperatures in rooms, fridges or other enclosed spaces. Needless to say, these instruments are capable of autonomous work, that is, they record temperatures over a defined period, without the need of a person meddling with it.

There are many various constructions available for data logging devices. Most of these devices have internal measuring sensors or can be linked to external sources. Also, most of these devices can be connected to via cord, RFID or a wireless system for data retrieval purposes, calibration or set up; many can also be set up and controlled via a personal computer or a smartphone. These devices are usually small, battery-powered, portable, equipped with internal memory for data storage, a connection for data retrieval of choice and sensors.

RS-232 and RS-485 Serial Communication Protocols

The RS232/485 port consecutively sends and receives bytes filled with information one bit at a time. Although the serial method is somewhat slower than parallel communication, which allows the transmission of an entire byte at once, it is far simpler and can be employed over longer distances because power consumption is lower than that of parallel one. As an example, the IEEE 488 standard for parallel communication requires that the cabling between equipment can be no more than 20 meters total, with no more than 2 meters between any two connected devices. On the other hand, RS232/485 cabling is possible to be extended 1200 meters or greater.
Typically, RS232/485 is employed to transmit American Standard Code for Information Interchange (ASCII) data. Although National Instruments serial hardware is able to transmit 7-bit as well as 8-bit data packages, many applications use 7-bit data. Seven-bit ASCII can represent the English alphabet, decimal numbers, and common punctuation marks. It is a standard protocol that virtually all hardware and software are able to comprehend. Serial communication is completed employing three transmission lines: (1) ground, (2) transmit, and (3) receive. Due to the fact that RS232/485 communication is asynchronous, the serial port is able to send and receive data on one line while also sending and receiving data on another. Other lines are also available, but are not required nor are they employed. The crucial serial characteristics are baud rate, data bits, stop bits, and parity. These parameters must match to allow communication between a serial device and a serial port on a computer.
The RS-232 port, or ANSI/EIA-232 port, is the serial connection which one is able to come across on most PCs. It is used for many purposes, such as connecting a mouse, a printer, or a modem, as well as other various industrial instrumentation. The RS-232 protocol is able to withstand only one device connected to each port. The RS485 (EIA-485 Standard) protocol is able to have 32 devices connected to each port. With this enhanced multidrop capability, one can create networks of devices connected to a single RS-485 serial port. Noise immunity and multidrop capability make RS-485 the serial connection of choice in industrial applications which are in need of many distributed instruments and peripherals connected to a PC or other controller for data collection.

I²C vs SPI - comparison

Bus topology / routing / resources

I²C needs two lines, while SPI officially defines at least four signals or more if more servants are added. Some informal SPI alternatives only need three wires, that is an SCLK, SS and a bi-directional MISO/MOSI line. Nevertheless, this exercise would require one SS line per servant. SPI lacks further work, logic and/or pins if a multi-master engineering must be built on SPI. The singular problem I²C when building a system is a finite machine address space on 7 bits, overwhelmed with the 10-bits enlargement.
From this point of view, I²C is a clear winner over SPI in sparing pins, board routing and how effortless it is to build an I²C network.

Throughput / Speed

If data must be relocated at ‘high speed’, SPI is apparently the protocol of choice, over I²C. SPI is full-duplex, and I²C is not. SPI does not determine any speed limit. Exercise often go over 10 Mbps. I²C is limited to 1Mbps in Fast Mode+ and to 3.4 Mbps in High-Speed Mode. This last one requires particular I/O buffers, not regularly easily available.

Elegance

It is usually said that I²C is much more elegant than SPI and that this last one is a very ‘rough’ protocol. People tend to think the two codes are equally elegant and comparable on robustness.
I²C is elegant for it offers very advanced appearances, such as automatic multi-master clashes handling and built-in addressing management, on a very light foundation. It can be very complex, nonetheless and somewhat lacks performance.
SPI, on the other hand, is quite easy to comprehend and to implement and offers a great deal of flexibility for extensions and alternatives. The disparity is where the elegance of SPI lies. SPI should be considered as a good platform for building custom protocol piles for transmission between ICs. Thus, in accordance with to the engineer’s need, using SPI may need more work but offers raised data transfer performance and almost total freedom.
Both SPI and I2C offer favourable support for connection with low-speed machines, but SPI is improved suited to applications in which devices assign data streams, while I²C is improved at multi master ‘register access’ application.

How do RS-232, RS-422, and RS-485 compare to each other?

RS-232 (ANSI/EIA-232 Standard) is the most widespread serial interface and it is used to ship as a standard component on most Windows-compatible desktop computers. Nowadays, it is more frequent to use RS-232 rather than using a USB and a converter. One downfall is that RS-232 only permits for one transmitter and one receiver on each line. RS- 232 also employs a Full-Duplex transmission method. Some RS-232 boards sold by National Instruments support baud rates up to 1 Mbit/s, but most devices are restricted to 115.2 kbit/s. On one hand, RS-422 (EIA RS-422- A Standard) is the serial connection employed primarily on Apple computers. It provides a mechanism for sending and receiving data up to 10 Mbits/s. RS-422 sends each signal employing two wires in order to increase the maximum baud rate and cable length. RS-422 is also specified for multi-drop applications where only one transmitter is linked to and sends and receives a bus of up to 10 receivers. On the other hand, RS-485 is a superset of RS-422 and expands on the capabilities of that previous model. RS-485 was manufactured to deal with the multi-drop limitation of RS-422, letting up to 32 devices to communicate through the same data line. Any of the subordinate devices on an RS-485 bus can communicate with any other 32 subordinate or ‘slave’ devices without the master device receiving any signals. Since RS-422 is a subset of RS-485, all RS-422 devices can be controlled by RS-485.
Finally, both RS-485 and RS-422 have multi-drop capability installed in them, but RS-485 allows up to 32 devices and RS-422 has a limit of only 10 devices. For both communication protocols, it is advisable that one should provide their own termination. All National Instruments RS-485 boards will work with RS-422 standards.

6 Steps on How to Learn or Teach LabVIEW OOP - Part 2

Step 4 – Practice!
This stage is harder than the last. You need to make sure:
Each child class should exactly reflect the abstract methods. If your calling code ever cares which sub-class it is calling by using strange parameters or converting the type then you are violating LSP – the Liskov substitution principle – The L of solid.
Each child class should have something relevant to do in the abstract classes. If it has methods that make no sense this is a violation of the interface segregation principle.
Step 5 – Finish SOLID
Read about the open-closed principle and the dependency inversion principle and try it in a couple of sections of code.
Open-closed basically means that you leave interfaces (abstract classes in LabVIEW). Then you can change the behavior by creating a new child class (open for extension) without have to modify the original code (closed to modification). This goes well with the dependency inversion principle. This says that higher level classes should depend only on interfaces (again abstract classes). This means the lower level code implements these classes and so the high-level code can call the lower level code without a direct dependency.
This goes well with the dependency inversion principle. This says that higher level classes should depend only on interfaces (again abstract classes). This means the lower level code implements these classes and so the high-level code can call the lower level code without a direct dependency. This can help in places where coupling is difficult to design out.
I leave these principles to the end because I think they are the easiest to write difficult to read code. I’m still trying to find a balance with these – following them wholeheartedly creates lots of indirection which can affect readability. I also think we don’t get as much benefit in LabVIEW with these since we don’t tend to package code within projects in the same way as other languages. (this maybe a good topic for another post!)
Step 6 – Learn some design patterns
This was obviously part of the point of this article. When I came back to design patterns after understanding design better and the SOLID principles it allowed me to look at the patterns in a different way. I could relate them to the principles and I understood what problems they solved.
For example, the command pattern (where you effectively have a QMH which takes message classes) is a perfect example of a solution to meet the open-closed principle for an entire process. You can extend the message handler by adding support for new message types by creating new message classes instead of modifying the original code. This is how the actor framework works and has allowed the developers to create a framework where they have a reliable implementation of control of the actors but you can still add messages to define the functionality.
Once you understand why these design patterns exist you can then apply some critical thinking about why and when to use them. I personally dislike the command pattern in LabVIEW because I don’t think the additional overhead of a large number of message classes is worth the benefit of being able to add messages to a QMH without changing the original code.
I think this will help you to use them more effectively and are less likely to end up with a spaghetti of design patterns thrown together because that is what everyone was talking about.
Urmm… so what do I do?
So I know this doesn’t have the information you need to actually do this so much as set out a program. Actually, all the steps still follow the NI course on OOP so you could simply self-pace this for general learning material.

3 Reasons to Automate your Business

Let's accept the fact that with every technological development that takes place, it's major focus is improved efficiency, cost cutting and better output. This is the major reason we are focused on the implementation of latest solutions for our businesses. An increasingly popular term that we come across is automation. And rightly so, it is the thing of the future which is slowly connecting all the aspects of industrialization. The process of automation, although a long one, can be easily implemented using the perfect blend of software and hardware. But what is it that makes automation our priority? Let's have a look at the three most important reasons behind this transition.

Filling the gap between supply and demand: We have to agree that with the ever increasing population, all the industries are always under the pressure of fulfilling high demand numbers. To tackle this problem, automation is an absolute necessity since it has helped increase the output multifold. This increase in the produce has also led to lesser wastage and optimum efficiency.

 Accuracy: Okay, let's just accept the fact that machine made material is better and precise when compared to the human hand. While more and more industries are making the shift to the automation technology, it is to be noted that their output has increased when compared to human support.

Cost cutting leads to increased efficiency: An automatic machine equals a hundred men. Well, even though this number might be accurate it is safe to say that a machine can give output which equals a lot of manpower. This not only saves money due to less investment in terms of salaries but also saves production time. Testing is easier and simplifies the production process.

So when we look at these factors, we realize how important automation actually is. But, as we mentioned before, complementing software is very important for such hardware and that is where ReadyDAQ jumps in. High end machinery makes use of a lot of operational devices and so ReadyDAQ offers a development solution for all its software needs without actually having to start from the scratch. Supporting simultaneous operation of multiple devices, it is the perfect solution for all industries trying to implement automation and it's components. So, what are you waiting for? Download the 30- day trial version today and get a feel of the product before making that purchase!

Automation to Replace Human Hands?

As we move deeper into the technologically advanced methodologies and manufacturing processes, we realize the power of the human mind. The mind which has developed a new league of technical procedures which have made our lives easy and working easier. Manual labor is on the way to extinction in a few years from now, thanks to the highly advanced machinery and automation industry. Automation, combined with the words automatic and execution have enabled a major chunk of processes to be executed without the human component. And with the amount of innovation taking place around the globe, it is surprising how robots and machinery have taken over the daunting human tasks.

But why do we support the intrusion of automation into our development process and how is it benefiting the industries? There is no doubt in the fact that machines can outperform humans in every aspect.

The precision and efficiency of an automatic machine are way better than a hundred humans working together. This is the most important reason as to why people prefer machines over man. While a human would numerous hours to assemble a product, a machine can manufacture and assemble the same within minutes. This not only saves a lot of time but expense as well. Automation in industries is a one-time investment which gives you long term benefits and efficient output. No doubt the machines demand maintenance, but it is still economical when compared to manual labor.

In huge manufacturing units, automation is a widespread concept which has taken over the human hand mainly because of the demand and supply chain where there is an excessively large need for manufactured goods.

But, it should also be noted that with an efficient hardware that goes into automating a factory, compatible and complementing software is also necessary. It is an intelligent software system that makes the machine efficient in providing optimum output. For this reason, ReadyDAQ your one stop shop for all the development needs has been created. It offers solutions to your software problems and is programmed to handle all operational devices such as pumps, motors, and sensors. A plug and play medium for devices, it helps the automation process in factories and industries by allowing the users to connect devices and without any major configuration or development operating it. It comes with a 30-day trial version to get a feel of the working before you actually make a purchase. So get yours today!

Embedded Controller for Data Acquisition

Embedded control is a subgroup of the overall data acquisition and control market. The I/O system is not connected to an external PC. The processor runs the system or the PC, which is incorporated into the I/O chassis itself, is the differentiating feature of an embedded system. One hosted DAQ system is usually introduced by some type of general purpose PC with a keyboard, monitor or some other human interface apparatus. However, an Embedded Control system's processor is normally designed specifically to control and monitor the system and often does not provide the direct connection to a monitor or any other human interface at all.

Still, the hardware differences between a standard PC and an embedded controller are evident. The differences in software are usually significant as well. Large operating systems (in terms of memory and disk space requirements) such as MAC OS X and Windows XP are the ones most PCs are based on, while the typical embedded system is more likely to be based on a smaller operating system developed to provide a simple and powerful GUI human interface. Nowadays, people are much more likely to work on operating systems such as Windows CE or Linux. Further, as many of these systems are in control of high speed or timing critical operations, people are much more likely to work on an embedded control DAQ system based on a real-time operating system such as RTX, QNX or Linux.

There is almost always some link to the outside world, even though the embedded control CPU is quite likely to run individually on any supervisory controller. Generally, it can be as complex as letting the supervisory computer take entire control any time the communication’s link between the two systems is active, but this may also be as limited as providing a simple "OK" or "not OK" situation. Usually, it is somewhere in between the supervisory control and data acquisition (SCADA) where computer looks over system status and provides a link that allows a human operator to manage the system's operation, or gives some direction (e.g. set points or PID control loop adjustments).

It is important to indicate that the heart of an industrial control system or a process control application is often some embedded controller. It should be at the center of a remote controller (that allows an application to keep running even if its significant link to the outside world is cut) or portable data acquisition system.

3 Steps to Understand RS232 Devices

 

Having troubles with controlling your RS232 device? This article will certainly help you understand almost all of the hardware and software standards for RS232.

Step 1: Understand RS232 Connection & Signals

RS-232C, EIA RS-232, or simply RS-232, refers to the same standard defined by the Electronic Industries Association in 1969 for serial communication.
DTE stands for Data Terminal Equipment. Any computer is a DTE. DCE stands for Data Communication Equipment. Any modem is a DCE.
DTE normally comes with a Male Connector, while DCE comes with a Female Connector. However, that is not always the case. Fortunately, there is a simple way to confirm this:
Measure Pin 3 and Pin 5 of a DB-9 Connector with a Volt Meter, if you get a voltage of -3V to -15V, then it is a DTE device. If the voltage is on Pin 2, then it is a DCE device. Simple and easy.
A straight-through cable is used to connect a DTE (e.g. computer) to a DCE (e.g. modem), all signals in one side connected to the corresponding signals in the other side in a one-to-one basis. A crossover (null modem) cable is used to connect two DTE directly, it does not require a modem in between. They cross-transmit and receive data signals between the two sides and there are many variations on how the other control signals are wired.

Step 2: Learn about the Protocol

A protocol is one or a few sets of hardware and software rules agreed to by all communication parties for exchanging data correctly and efficiently.
Synchronous and Asynchronous Communications
Synchronous Communication requires the sender and receiver to share the same clock. The sender provides a timing signal to the receiver so that the receiver knows when to "read" the data. Synchronous Communication generally has higher data rates and greater error-checking capability. A printer is a form of Synchronous Communication.
Asynchronous Communication has no timing signal or clock. Instead, it inserts Start / Stop bits into each byte of data to "synchronize" the communication. As it uses fewer wires for communication (no clock signals), Asynchronous Communication is simpler and more cost-effective. RS-232 / RS-485 / RS-422 / TTL are the forms of Asynchronous Communications.

Drilling Down: Bits and Bytes

Internal computer communications consist of digital electronics, represented by only two conditions: ON or OFF. We represent these with two numbers: 0 and 1, which in the binary system is termed a Bit.
A Byte consists of 8 bits, which represents decimal number 0 to 255, or Hexadecimal number 0 to FF. As described above, a byte is the basic unit of Asynchronous communications.

Step 3: Control your RS232 devices

After reading and understanding the first two steps we’ve talked about, it is easy to now test and controls your RS232 devices in order to get the perfect feel of how they work.
ReadyDAQ offers software solutions for RS232 devices, make sure to check them out.

INTRODUCTION TO RS232 SERIAL COMMUNICATION - PART 2

Assume we want to send the letter ‘A’ over the serial port. The binary representation of the letter ‘A’ is 01000001. Remembering that bits are transmitted from least significant bit (LSB) to most significant bit (MSB), the bit stream transmitted would be as follows for the line characteristics 8 bits, no parity, 1 stop bit, 9600 baud.

LSB (0 1 0 0 0 0 0 1 0 1) MSB
The above represents (Start Bit) (Data Bits) (Stop Bit)
To calculate the actual byte transfer rate simply divide the baud rate by the number of bits that must be transferred for each byte of data. In the case of the above example, each character requires 10 bits to be transmitted for each character. As such, at 9600 baud, up to 960 bytes can be transferred in one second.
The first article was talking about the “electrical/logical” characteristics of the data stream. We will expand the discussion to line protocol.
Serial communication can be half duplex or full duplex. Full duplex communication means that a device can receive and transmit data at the same time. Half duplex means that the device cannot send and receive at the same time. It can do them both, but not at the same time. Half duplex communication is all but outdated except for a very small focused set of applications.
Half duplex serial communication needs at a minimum two wires, signal ground, and the data line. Full duplex serial communication needs at a minimum three wires, signal ground, transmit data line and receive data line. The RS232 specification governs the physical and electrical characteristics of serial communications. This specification defines several additional signals that are asserted (set to logical 1) for information and control beyond the data signals and signals ground.
These signals are the Carrier Detect Signal (CD), asserted by modems to signal a successful connection to another modem, Ring Indicator (RI), asserted by modems to signal the phone ringing, Data Set Ready (DSR), asserted by modems to show their presence, Clear To Send (CTS), asserted by modems if they can receive data, Data Terminal Ready (DTR), asserted by terminals to show their presence, Request To Send (
RTS), asserted by terminals when they want to send data. The section RS232 Cabling describes these signals and how they are connected.
The above paragraph alluded to hardware flow control. Hardware flow control is a method that two connected devices use to tell each other electronically when to send or when not to send data. A modem in general drops (logical 0) its CTS line when it can no longer receive characters. It re-asserts it when it can receive again. A terminal does the same thing instead with the RTS signal. Another method of hardware flow control in practice is to perform the same procedure in the previous paragraph except that the DSR and DTR signals are used for the handshake.
Note that hardware flow control requires the use of additional wires. The benefit to this, however, is crisp and reliable flow control. Another method of flow control used is known as software flow control. This method requires a simple 3 wire serial communication link, transmit data, receive data, and signal ground. If using this method, when a device can no longer receive, it will transmit a character that the two devices agreed on. This character is known as the XOFF character. This character is generally a hexadecimal 13. When a device can receive again it transmits an XON character that both devices agreed to. This character is generally a hexadecimal 11.

Synchros and Resolvers

Synchros and Resolvers have been used to measure and control shaft angles in various applications for over 50 years. Though they predate WWII, these units became extremely popular during WWII in fire/gun control applications, as indicators/controllers for aircraft control surfaces and even for synchronizing the sound and video in early motion picture systems. In the past, these units were also called Selsyns (for Self-Synchronous.)
At a first glance, Synchros and Resolvers don’t look too different from electric motors. They share the same rotor, stator, and shaft components. The primary difference between a synchro and a resolver is a synchro has three stator windings installed at 120-degree offsets while the resolver has two stator windings installed at 90-degree angles. To monitor rotation with a synchro or resolver, the data acquisition system needs to provide an AC excitation signal and an analog input capable of digitizing the corresponding AC output.
Though it is possible to create such a system using standard analog input and output devices, it is a fairly complicated process to do so, and most people opt for a dedicated synchro/resolver interface. These DAQ products not only provide appropriate signal conditioning, they also typically take care of most of the “math” required to turn the analog input into rotational information. It always a good idea to check the software support of any synchro/resolver interface to ensure that it does provide results in a format you can use. Most synchro/resolvers require an excitation of roughly 26 Vrms at frequencies of either 60 or 400 Hz. It is important to check the requirements of the actual device you are using. Some units require 120 Vrms (and provide correspondingly large outputs…be careful.) Also, some synchro/resolver devices, and in particular those used in applications where rotational speed is high, require higher excitation frequencies, though you will seldom see a system requiring anything higher than a few kilohertz.
Finally, some synchro/resolver interfaces such as UEI’s DNx-AI-255 provide the ability to use the excitation outputs as simulated synchro/resolver signals. This capability is very helpful in developing aircraft or ground vehicle simulators as well as for providing a way to test and calibrate synchro/ resolver interfaces without requiring the installation of an actual hardware. Note: In some applications, the synchro/resolver excitation is provided by the DUT itself. In such cases, it is important to make sure that your DAQ interface is capable of synchronizing to the external excitation. This is typically accomplished by using an additional analog input channel.

Simple Wiring of Clock and Trigger

One last part of "non-standard" information obtaining and control frameworks is the manner by which bigger frameworks are synchronized. Regularly, it is important that you know "what" happened, as well as "when" it happened. In little frameworks, this is normally simple to fulfill as the simple sources of info and even the yield excitation, are on a similar board. Be that as it may, frameworks with high channel include and, specific, applications spread over extensive zones require cautious thoughtfulness regarding timing. A top to bottom talk of this theme is well past the extent of this article, yet the accompanying brief segment may help the per user begin off in the correct bearing instantly.

Simple Wiring of Clock/Trigger

Simple Wiring of clock and trigger signs is regularly the snappiest, least demanding and most exact approach to synchronize occasions in better places. Most DAQ gadgets have at least one trigger/clock sources of info and it is as often as possible conceivable to just synchronize frameworks by interfacing these signs. Take note of that the engendering of an electronic flag in a wire is near the speed of light. A thousand feet of wire would commonly just present about a microsecond of postponement.
A great many people consider GPS (Global Positioning System) as a reasonable approach to discover the closest corner store or pizza parlor. Be that as it may, GPS is likewise a magnificent innovation for giving extremely exact time data. Truth be told, the whole reason for the GPS framework is amazingly exact timekeepers (and in addition satellites at known areas). Indeed, even a generally economical GPS can give supreme planning precision superior to 1 microsecond. In spite of the fact that the GPS on your pontoon or auto might not have a period yield flag, numerous reasonable GPS gadgets give a 1 or 5 Pulse for every Second flag exact to inside 1 uS of supreme UTC. Utilizing these straightforward and reasonable gadgets, it turns out to be straightforward to synchronize information tests anyplace on the planet.

Do You Know About RS-232/422/423/485?

Individuals initially started anticipating the downfall of RS-232 in the 1980s. Obviously, RS-232 is still around and kicking. On the off chance that Mark Twain was as yet alive, I'm certain he'd compose something on the request of "The reports of the demise of RS-232 have been enormously overstated". The RS-arrangement ports remain to a great degree basic in the information procurement and control field.
RS-232 is more established and slower than its 422/423/485 family mates, yet the use of both is still extremely normal. As a genuinely straightforward interface, there is not all that much to consider while determining an RS-arrangement interface, yet a couple words might be all together. In the first place, not every single serial gadget work at a similar speed. Make certain to determine a gadget that will deal with the baud rate of your gadget. Second, for steady and reliable operation, particularly at higher rates, make certain to choose a gadget with a significant FIFO. Take note of that RS-232 ports, and specifically, those on more established gadgets, utilize equipment handshaking signs, for example, "Prepared to Send", "Clear to Send".
Numerous more up to date RS-232 interfaces don't bolster these handshaking signals, so make sure to watch that your serial interface underpins what you require. Another normal arrangement of inquiries emerges while considering the contrasts between RS-422, 423 and 485. RS-422 utilizations a two-wire, completely differential flag interface. RS-423 utilizations the same signal levels, however, utilizes just a single of the two wires. RS-422 and RS-485 are practically indistinguishable. The distinction is that an RS-485 is networkable and can be associated with various serial gadgets. An RS-485 interface will quite often be superbly appropriate for conversing with an RS-422 gadget

Military’s equivalent to ARINC-429

MIL-STD-1553 is the military’s equivalent to ARINC-429, though structurally it is VERY different. The first and most obvious difference is that most 1553 links are designed with dual, redundant channels. Though commercial aircraft don’t typically get wires cut by bullets or flak, military aircraft are typically designed such that a single cut wire or wiring harness won’t cause a loss of system control.
If you are looking to “hook” to an MIL-1553 device, be sure your interface has both channels. Also, an MIL-1553 device can serve as Bus Controller, Bus Monitor, or Remote Terminal. Not all interfaces support all three functions. Be sure the interface you select has the capability you require. As with the ARINC-429 bus, when operating as a bus controller, the unit must be capable of detailed transmission scheduling (including major and minor frame timing) and this is best performed in hardware rather than via software timing.

CAN 

The CAN (Controller Area Network) bus is the standard communications interface for automotive and truck systems. Gone are the days when your car was controlled by mechanical linkages, gears, and high current switches. Your transmission now shifts gears based on CAN commands sent from a computer. Even such things as raising/lowering the windows and adjusting the outside rearview mirror are frequently no longer done via simple switches but are now done via CAN sensors and actuators.
Vehicle speed, engine RPM, transmission gear selection, even internal temperature are all available on the CAN bus. As with the ARINC-429 aircraft example, when running tests in a car or truck, it’s very useful to be able to coordinate the data available on the various CAN networks with any more conventional DAQ measurement you may be making. If you are measuring internal vibration, you’ll want to coordinate it with Engine RPM and speed (among other things). Like any data acquisition system, one of the first things you need to be aware of when specifying a CAN interface system is how many CAN ports you will need.
There are sometimes 50 or more different CAN networks in a given vehicle. Be sure your system has enough channels to grab all the data you still need. The CAN specification supports data rates up to 1 megabaud. Be sure the system you specify is capable of matching the speed of the network you wish to monitor

Quadrature Encoders

Quadrature encoders are likewise used to quantify rakish relocation and turn. Not at all like alternate gadgets, we have portrayed in this article, these items give a computerized yield. There are two essential computerized yields which are as 90-degree out-of-state advanced heartbeat trains. The recurrence of the beats decides the rakish speed, while the relative stage between the two (+90°or - 90°) portrays the bearing of turn.
These heartbeat trains can be checked by numerous nonspecific DAQ counter frameworks with one of the outputs being associated with a counter clock while the other is associated with an up/down stick. In any case, the encoder is such a typical piece of numerous DAQ frameworks that numerous merchants give an interface particularly created to quadrature estimations. One thing that can't be resolved from the beat tallies alone is the outright position of the pole.
Thus, most encoder frameworks likewise give a "File" yield. This list flag produces a heartbeat at a known rakish position. Once a known position is distinguished, the supreme position can be controlled by including (or subtracting) the relative pivot to the known record position. Numerous encoders give differential yields, however, differential commotion resistance is sometimes required unless the electrical condition is extremely cruel (e.g., neighborhood circular segment welding stations) or the keeps running from the encoder to the DAQ framework are long (100s of feet or more). Committed Encoders are accessible from numerous sellers in an assortment of setups.
ICP/IEPE Piezoelectric Crystal Sensors When considering piezoelectric precious stone gadgets for use in a DAQ framework, the vast majority consider vibration and accelerometer sensors as these gems are the reason for the pervasive ICP/IEPE sensors. It is by and large comprehended that when you apply a drive on a piezoelectric precious stone it makes the gem twist marginally and that this distortion incites a quantifiable voltage over the gem. Another component of these gems is that a voltage set over an unstressed piezoelectric precious stone makes the gem "distort".
This miss happening is in reality little, additionally exceptionally very much carried on and unsurprising. Piezoelectric precious stones have turned into an extremely normal movement control gadget in frameworks that require little avoidances. Specifically, they are utilized as a part of a wide assortment of laser control frameworks and also a large group of other optical control applications. In such applications, a mirror is connected to the gem, and as the voltage connected to the gem is changed, the mirror moves.
In spite of the fact that the development is ordinarily not discernible by the human eye, at the wavelength of light, the development is significant. Driving these piezoelectric gadgets presents two fascinating difficulties. To start with, accomplishing the coveted development from a piezoelectric precious stone frequently requires huge voltages, however benevolently at low DC streams. Second, however, the precious stones have high DC impedances they additionally have high capacitance, and driving them at high rates is not a minor undertaking. Exceptional drivers, for example, UEI's PD-AOAMP-115 are regularly required as the run of the mill simple yield board does not offer the yield voltage or capacitive driveability required.