FAQ

PLC stands for Programmable Logic Controller. It is a controller that acts like the "brain" of a machine: it makes high-level decisions and controls the functions of a production machine. In industry, PLCs handle tasks such as motion control and process monitoring. A single PLC can serve as the central controller for an entire system, under which there may be several other PLCs. PLC controllers can be used in virtually any industrial automation task.

Both nothing and everything! The basic idea is the same: programming the logic that controls machines and processes. The differences are more superficial — typically manufacturers provide their own programming tools, whose user interfaces and the syntax of their programming languages (i.e. how commands must be written so the machine understands them) tend to differ. 



Once you understand fundamental logic, switching manufacturer is usually just a matter of learning a new tool.

Technically usually yes, but in practice it's seldom worthwhile. The problem is that old programs rarely fit neatly into the requirements of the renewed project. For example, in an old production line you might not want to replace the entire machine, but its program might have reached end-of-life. If the program is transferred as-is, you also carry over all the modifications, fixes, or deprecations that have accumulated during the machine's lifecycle — often including unnecessary code. And if during the project there is a need to add modern requirements, the old code usually does not adapt very cleanly — which increases the cost.

Starting from a clean slate and building a new solution according to modern standards is often the most cost-effective option in the long run. 

It’s better for everyone to not try reusing the old program, but instead clarify exactly what functionalities are needed and build a new solution. A video or documentation of the machine running gives a far clearer picture of what we need to achieve than relying on outdated code.

This depends entirely on the case. The more precisely the goals and needs are identified and defined at the beginning, the more realistic the schedule you can get.



Along the way, there are often realizations and additions. The best starting point is a good preliminary assessment — but leave flexibility in the plan for possible changes.

This is quite a big topic, typically belonging more to mechanical design than pure programming. For example, there might be risks of crushing, and safety definitions are governed by machinery directives. Modern machines often include redundant safety circuits and safety logic that operate separately from the main production program. Safety interlocks such as door safety switches and emergency stop circuits are connected to these safety circuits. When a door is opened or a safety device is triggered, the machine is brought to a safe state — for example by releasing pressure or cutting off control voltage and compressed air.



Error handling means that the program detects abnormal situations and reacts in a defined way (e.g. alarms and/or halting processes). With good design and structured approach, the program can also recover from exceptional situations correctly — regardless of what the user does or in what order. A well-designed program should not even allow improper user actions.

In PLC programming, several specialized languages are used; most are based on the IEC 61131-3 standard. We most commonly use the following three.

Ladder Diagram (LD)

Also known as "ladder logic." This graphical language was developed so that, e.g., electricians and automation engineers could easily understand its structure, since it resembles electrical circuit diagrams. It is especially suitable for relay logic and control implementations. For example, LD is common with Omron.

Function Block Diagram (FBD)

Another graphical language, where the program is built from functional blocks. It is well suited for process control and PID regulation (e.g. controlling a furnace temperature to stay at a desired value). FBD is used, for instance, by Siemens.

Structured Text (ST)

A textual, conventional programming-language–like syntax. ST is quite similar across manufacturers, so when we write ST inside so-called function blocks, we can often copy that code almost directly to another manufacturer’s environment. That saves a lot of time and therefore costs.

In many ways! The IT-side and industrial automation side increasingly overlap. Common methods include industrial fieldbuses such as EtherCAT and PROFINET, as well as older systems such as Profibus. Additionally, connections can be hard-wired — via direct inputs/outputs or voltage-based signal lines.



Nowadays it's also common to use Ethernet-based industrial protocols (e.g. OPC UA) or general IP-based solutions between devices. Where in the past separate middleware or PC connections were often required, modern PLCs can read and write data directly — for example into databases.

The same answer applies as with differences between manufacturers: both nothing and everything! What is distinctive is using languages like Ladder, which you rarely see elsewhere. Though like other programming languages, PLC languages vary in syntax and representation, if you know how to think in terms of good design — how to build machine control in an efficient, systematic way — then you can apply those skills in almost any programming environment.

We’re often asked this! The small differences between manufacturers can be learned quickly when you have a good foundational understanding of how machines and automation work. What matters most is the ability to build logic and structure processes correctly — not whether you’ve worked with a specific brand before.

Different manufacturers have their own programming commands and methods — but again we return to the fact that the core idea is the same as any programming: you create a program that the device executes.

The special aspect with industrial robots is that they must control their movements in three-dimensional space. As programmers, we must understand coordinate systems and math, because the robot constantly computes where it currently is in space and where it needs to go next.



The program is executed slightly differently: the controller must have time to calculate the robot’s motions. For example, a six-axis robot controls six servo motors simultaneously. Each motor’s movement affects the whole, and their combined action produces the precise robot trajectory. Even motions that appear simple actually involve a vast amount of computation behind the scenes.

Not very directly, because manufacturers have their own programming environments. The best approach is to leverage previous experience and the general way of thinking — the principles of building the process apply regardless of brand. But the actual program must always be written in the manufacturer’s own environment.

Most robot manufacturers provide their own programming tools or paid add-ons for this. For instance, with a manufacturer’s tool you can define virtual boundaries for the robot — a space within which the robot is allowed to operate. Even if the program tells the robot to move to a forbidden zone, it will stop at the boundary.

Another essential safety function is collision detection. Manufacturers implement this differently, but almost all rely on monitoring the servo axes’ current values. If a limit is exceeded, some provide a custom protocol for post-collision behavior; instead of a “tilt,” the system switches to an interruption routine: for example, the robot stops, returns to a safe position, and sends a signal to the PLC.

In collaborative robots (robots that work with humans), protective enclosures may not always be needed. Instead, the robot’s motions are made deliberately slow, so that in case of a collision, the speed is low enough to be safe for a human. The downside is reduced throughput — but if the process isn't time-critical, that's often a reasonable trade-off.

First the program must run reliably. Then we observe — we monitor the robot cycle, and based on that we start fine-tuning motion speeds and accelerations.



Optimization allows removing unnecessary steps and streamlining the process as much as possible. For example, if a robot is waiting a long time for another machine step, it doesn’t make sense for it to run at full speed while waiting — slower motion may be good enough.

Each robot manufacturer has its own languages, although the syntaxes often resemble each other. For example, a manufacturer may use KRL (for KUKA robots), which is in many ways similar to the PLC’s Structured Text — so it is fairly easy to grasp, even if there are manufacturer-specific nuances. For Yaskawa robots, however, the language may be entirely different and proprietary.



Once you understand the basic principles of robot programming, learning a new language is usually straightforward.

As we stated earlier: in most respects, it's like any other programming, but it involves movement and using a coordinate system — aspects you rarely see in other languages.

Common motion commands for robots include:

• Joint move — the robot computes each axis position itself, as long as the tool ends up at the desired point and orientation. This is often used in free space, because the programmer doesn't have to define the exact path; the command is the same, but the robot optimizes the path internally. 
• Linear move — the robot must keep the tool’s orientation exactly correct along a straight line, for example, when a gripper must remain perpendicular while moving. 
• Circular move (arc move) — motion along an arc or circular path.



In robot programming we also heavily use coordinate calculations. For example, when a robot places boxes on a pallet, you don’t teach each box position individually. Instead you define a coordinate system and calculate displacements in X, Y, and Z directions — then the robot moves to the calculated points.

Communication occurs either via an industrial bus or via hard-wired I/O. With a bus solution, you can send more than just binary signals — for example, coordinates and orientation data from a machine-vision system.

This is quite often asked. As long as you master the fundamentals of robots and automation, the small differences between manufacturers are easy to learn. What matters most is your understanding of the underlying principles — not whether you have previously worked with that specific manufacturer.

To begin with, it is worth noting that Tricycle Software is responsible specifically for programming and software development in automation projects, so we answer this question primarily from that perspective.

The project begins with as thorough a discovery phase as possible. The goal is to ensure that both the supplier and the customer have the same understanding of what is actually being built. Most pitfalls in automation projects arise from misunderstandings or from situations where real costs or requirements were not properly identified during the initial phase.

During the discovery phase, we go through in detail what the system is expected to do and in what kinds of situations it will be used. The better the customer can describe real operating scenarios, the easier it is to design a system that truly supports production. At this stage, nothing should be taken for granted.

Once the direction of the project is clear, the programming work begins. During the project we organize regular review sessions—preferably more often than less—where we go through what has been done and how the implementation is progressing. Frequent reviews usually lead to a better end result.

When the system or machine begins to function, the next important phase is user testing. It is essential that the people who will actually operate the machine get to test it. A software developer is rarely the best tester, because they naturally assume the machine will be used in a certain way. Someone else may approach it with a completely different mindset.

For this reason, tests are often carried out without explaining the system in detail beforehand. This helps reveal how intuitive the user interface really is without prior training. Based on these tests, the system can still be adjusted so that incorrect operation is not even possible.

Before the machine is delivered to the customer’s production environment, it must pass a Factory Acceptance Test (FAT). Prior to that, we typically carry out more informal testing to ensure that the system actually meets the customer’s real needs. The final acceptance, the Site Acceptance Test (SAT), takes place at the customer’s production facility during commissioning.

Automation removes physically demanding and repetitive tasks from production. In countries like Finland, manufacturing costs are high, and competing with low-cost countries purely on labor costs is difficult. One of the most effective ways to remain competitive is through automation.



In the past, automation was often criticized for eliminating jobs. To some extent this is true, but it also allows people to focus on tasks where human skills are most valuable. At the same time, automation has created entirely new types of jobs, for example in equipment manufacturing, programming, maintenance and service.

Automation today is no longer just about moving pneumatic cylinders. In modern production environments, automation systems almost always need to integrate with other systems.



Production equipment may need to exchange data with ERP systems, MES systems, quality systems or other machines on the production line. Integration is therefore a normal and expected part of modern automation projects.

A maintenance system helps shift maintenance from reactive to predictive. Instead of responding to failures after they occur, components can be replaced before they break.



This significantly reduces unexpected downtime, as maintenance shutdowns can be planned in advance based on actual operational data.

A maintenance system can be a separate external system connected to the equipment. It can also be integrated into the automation itself, where the software collects operational data from the machine, analyzes it and provides predictive information to operators or maintenance personnel—for example when a component may be approaching the end of its service life.

The biggest risk is insufficient discovery at the beginning of the project. If the initial assessment is not thorough enough, the customer and the supplier may end up having different expectations about what is actually being built.



Another important factor is communication during the project. If challenges arise, it is essential to communicate them openly and early. Honest and transparent communication significantly reduces project risks.

Jere from Tricycle is not only a programmer but also a mechanical engineer. This means there is a solid understanding of machines and of what automation requires to function properly, both from a software and a mechanical perspective.



Our trademark is user-centered programming and intuitive user interfaces. This cannot be emphasized enough: the software should not even allow incorrect use.

To prepare a quote, we need as accurate a picture as possible of what the system is supposed to do.



One critical phase that the customer may not necessarily think about is testing and the material required for it. If the project includes testing with material, it is important to reserve sufficient test material. It is often difficult to estimate how much material is needed for proper testing. The system should be able to run, if necessary, for several hours so that its operation can be reliably tested before the actual trial run.

The project start schedule depends entirely on the situation. If the current workload is not very heavy, a new project can usually be started fairly quickly.

Most often yes, at the latest during commissioning.



Whenever possible, we also aim to establish remote access to the system. This allows us to respond quickly to situations during the early stages of the machine’s lifecycle and provide support without the delays caused by travel.

Yes, we do. Support can be provided either remotely or on-site.

Especially in situations where comprehensive test runs have not been possible in advance, observations may arise during production that require further development of the system. In such cases, support is essential to ensure the equipment operates as intended.



And when it happens that the customer later wants a modification to the system, it is usually most natural to order the work from the supplier who originally developed the software.

GMP, or Good Manufacturing Practice, refers to quality practices and operating principles applied particularly in the production of pharmaceuticals, food products, and other strictly regulated goods.



In a GMP environment, one important role of software is to prevent users from making mistakes that could compromise traceability or product quality. In practice, this may mean that the system does not allow a production batch to start without the required material information and does not accept incorrect materials into the process. This helps avoid situations that could lead to deviation reports, rejected batches, or in the worst case, product recalls.

In software development, GMP is reflected especially in traceability and controlled change management. All software changes are documented, versioned, and tested before deployment. A clear development history is maintained, and no changes are made to the production system without proper control.

Yes. You can also request consulting support when needed.

In most cases, yes. We protect our own standard software libraries, but the development work carried out for the project remains with the customer. The software can be further developed by anyone, and the customer is free to choose the next software developer if modifications are made to the equipment. Our responsibility is to deliver software of such quality that the customer chooses to work with us again.