Add a controller in the Solution Center

The Solution Navigator is located in the left-hand section of the Solution Center. This is your project tree, so to speak. Anything can belong to a solution:

• Templates
• M-PLC projects
• Online-Devices
• Offline-Devices
• ...

As already listed, there are so-called online devices and offline devices:

• Online devices are effectively just connection configurations to real existing physical devices. If a device is accessible, its configuration is read out and displayed under the online device as a configuration tree.
Offline devices can either be
• Backups of real existing physical devices: You can create an offline device from an online device. This creates an offline copy that you can use as a backup.
Devices planned on the green table, whose configuration is later transferred (deployed) to real devices.
• Online and offline device always go together to form one device.

As the online devices only contain connection configurations, you only need to create them once if you always work with controllers with the same IP addresses. Then create a solution that you can use for all your projects. Unused devices are simply "dead" in the solution: these devices cannot be reached.

To add a new solution, right-click on the "Solution projects" element and select "New => Solution". Enter a descriptive project name. For example, "Test system".
A project with a template folder has now been created.
To create a device, right-click on the project folder again and select "New => Device". In the new window, you can now decide once again under which project the device is to be created.
In the following dialog, you have the option of searching for a device or setting it up manually:

• You can search your current network (depending on the IP of your network card).
• You can specify an IP address range in which to search.
• Searching across routers does not work. The device must be in the same physical network as your PC.
• In the search results, individual controllers will appear multiple times. The reason is unclear.
• You can make individual devices flash and also change the IP. To do this, the switches must be set to PROG/3.
• You can create a device manually, for example if you do not have a network connection to the device or need to add devices in another network.
• The latest generation of controllers can also be addressed directly via USB (the small USB socket, not the large one).
• If you have redundant devices, check the "Redundant" box, then the second device will be configured directly in the connection and both will be grouped in the project tree.

Give the device a descriptive name, for example "Main controller" or "Substation".
Click on "Finish" - the other setting options are generally not relevant if you are working with the default settings.
Done!
You now have a new device in your project tree, which has both an online and an offline device.
You can now communicate with the real device via the online device or configure it online.

You can also find a quick guide for download in our library under Bachmann / HowTos, Tips and Tricks / Solution Center: How do I start.

go to top...

---

Programming

Programming can (still) be carried out in two different development environments: The (old) M-PLC, a CoDeSys interface, and the (new) PLC Developer, which is integrated in the Solution Center. New programs should always be developed in PLC Developer, as this has a number of advantages. go to top...

PLC Developer

The CoDeSys programs are always available as a single file, the .PRO file. Archiving in a versioning system is therefore not possible, as only the entire file can be archived and no individual changes can be traced.
It is also an external tool that has to be maintained. And debugging is not really convenient. Bachmann has therefore decided to integrate its own development environment into the Solution Center.
This still uses M-PLC in the background, but only to compile the code. The PLC Developer stores all source code components as files. This means that every function, every program and every variable table is a file. In this way, a versioning system can log every change to the source code. For the user, it also has the advantage that many convenience functions have been implemented by Bachmann:

• Templates with variables can be created for each program component (program/function/function block/...). For example, a file header that is always the same can be predefined, in which the creation date and creator are automatically entered.
• An extensive auto-completion function has been implemented.
• There are code templates that can be extended and used via keywords.
• Detailed tooltip windows with parameter help are available - this is also where the standardized headers come into play: This also works with self-written functions!
• Convenient debugging with context highlighting and change highlighting.
• Libraries are stored in the project, so there is a consistent version of the library used. Updates must be made explicitly and manually.
• From CFC plans, webMI visualizations can be generated automatically in order to debug program code via the HMI.

The PLC-Developer is constantly being developed further. At the moment it can be used to program in ST and CFC. If someone prefers/needs other languages, he must continue to program with M-PLC.
However, there are also (currently still) some disadvantages:

• There is no context help yet. You cannot press F1 for a questionable function and the help is automatically called up. You have to search the manual yourself.
• Actions in function blocks/programs are not displayed in separate windows, but folded in under the main function.
• There is no simulation function.
• There is no visualization editor.

All that glitters is not gold, but on the whole the PLC Developer is a big step forward compared to the outdated interface of M-PLC.

Open the "PLC Developer" perspective for programming.
Create your program in the usual way. You can organize your source code files in folders.
In PLC Developer, programs can be compiled by right-clicking on the program, cleaned up and transferred to the PLC with "Execute as". To do this, an "Execute as..." configuration must be created. Here you can specify whether the program is to be transferred to a specific PLC or whether the controller is to be queried each time the program is executed. Each online device can be selected in the solution tree. The user can also specify whether the program is installed permanently or only temporarily until the PLC is restarted.

go to top...

M-PLC

M-PLC is the original development environment from Bachmann. It is based on CoDeSys 2.3 and can therefore also be used immediately by newcomers from other CoDeSys systems.
However, new programs should be developed with PLC Developer, as this offers more convenience and will probably replace M-PLC completely in the long term.

go to top...

Connecting a PLC unit with M-PLC

M-PLC is only the programming tool. No hardware configuration is created with M-PLC. Therefore, M-PLC must first be informed of the device to be programmed. This is done via the "Target manager" utility program. You can find it in the start menu under "Bachmann =< M1 Software" and then in the tray with the following icon:



Double-click to open it:



All controllers with which you can communicate in M-PLC are listed here. The names assigned here appear again in M-PLC:



But more on that in a moment...
First of all, the controller must be added to the TargetManager. To do this, click on "Add...".
Now enter a descriptive name for the controller. The description is only a comment and is not necessary. Now enter the IP of the controller under which you have also integrated it in the SolutionCenter. If you encounter timeout problems later when installing the software, you can try to increase the waiting time for this control unit. Experience has shown that values of 30-50 seconds are sufficient.
Then click on "Close", not on "Exit".

You have now laid the foundation on which we can build in the M-PLC. Now start this - either with an existing project or create a new one.
With the project opened, go to "Online =< Communication parameters..." and you will see the window shown above.
Here you can now make some M-PLC-specific settings:
Select the controller to which the program is to be transferred. If the same program is to be loaded on two controllers (e.g. for redundant projects or for two controllers with the same program), you can check the "Redundancy" box and select a second controller.
SW module name specifies the name under which it is uniquely identified in the controller. Background:
You can call up the same program several times (e.g. with different parameters). Each instance is given its own SW module name so that it is uniquely identified. The module name also appears afterwards in the SolutionCenter in the online device.
The name must not contain any special characters, except for the underscore (_). The name must not be longer than 8 characters and is always interpreted in capital letters. By default, the name of the saved M-PLC project is shortened to 8 characters. However, you can also freely select it.
Under Installation settings, you must check "Install permanently" so that the boot project is created and the program is started every time the controller is started. Otherwise, just copy the program, load it, but it will not be loaded when the control unit is restarted as it is not entered in mconfig.ini. This field may still be grayed out when configuring the controller in M-PLC for the first time. In this case, set the controller, close the dialog and open it again, then you can check the box.
You do not usually need to adjust the path. The projects are copied to the APP directory on the boot medium. If you want a different directory (for example, FLASH is the boot medium, but the programs are to be stored on the CFC), you must specify the path here: /cfc0/app/.
Below you can see which projects are already installed on the controller for information purposes only.

go to top...

---

The most important differences to Siemens. OR Basics of the Bachmann controller.

If you come from the Siemens world, you have in your head: one controller = one program. All configuration is done in the program.
You have to say goodbye to that here!
Think of the controller as a PC, with all its possibilities - then you will understand better where the rabbit is running.

So you have a PC (the controller), on which you first have several storage media (e.g. flash/cfc/USB). These storage media can have several partitions (e.g. cfc0, cfc1, cfc2). The operating system with all its data (operating system kernel, drivers, system data, programs, configuration) is stored on these media - to which you have full access. You can determine which data is stored where, you can determine which medium you boot from. You can determine everything yourself - if you want. You don't have to, but you can. Of course, you can also "break" everything (not physically, but functionally).

So you do not have ONE program on ONE controller. You have any number of programs (limited by the CPU and memory, of course) on one controller. These programs are individual files. The *.m files. Each program can be called up in one or more instances. Several tasks can also be written in one program in M-PLC, which run in parallel.

You have full access to the controllers and the entire content of all storage media via FTP. You can therefore make backups as required, store copies on the controller and even copy your complete finished project to the controller later, so that the current project is always stored on the controller.

The entire configuration is only stored in one place: The mconfig.ini file in the root directory of the boot medium. There is no other location, only this one. And this file is a plain text file, readable. If you copy an mconfig.ini with a known IP to a USB stick and start the controller from USB instead of flash or CFC, you can address any controller, even if you do not know the IP. You then read the mconfig.ini on the controller and know which IP the controller has. It couldn't be simpler.

This is the great advantage of this system: you have a human-readable configuration file that contains the entire configuration. You can generate the content in any way you like: via the Solution Center interface, via Excel, via text templates, via your own configuration tool, ... everything is possible.
However, this is also a major disadvantage because the SolutionCenter interface is not always suitable for mass parameterization. If you have several distributed stations that communicate with each other, you cannot compare the configurations with each other - but you can copy them from one station to another.

There is no online/offline comparison with CoDeSys. As the compiled program is copied to the controller, the versions can only be compared using the checksum and the date. Detailed comparisons are only possible with different offline program versions in M-PLC.

As you can see, this is a completely different philosophy compared to conventional industrial control systems. But compared to a PC, I think it's easy to understand.

go to top...

---

Where are my data modules? OR How do I organize my global data?

CoDeSys lacks the concept of "data blocks". There are instances of FBs, but these are created in the calling program or globally as a variable, not as an instance DB.
All global data is created in variable lists. To do this, go to the "Resources" tab at the bottom left of the navigation area in M-PLC. You will then see a "Global variables" folder at the top. Here you can create different variable lists.
In each list you can define the areas VAR_GLOBAL/END_VAR as often as you like. You can also assign key words to each area. For example

• REDUEX: Variables declared in this way are not taken into account in the redundancy
• RETAIN: Variables declared in this way are retained even after a power failure
• CONSTANT: Constants, not changeable during the cycle

This means that you can use these variable lists to create global DBs in which you can structure data.

go to top...

---

Where are my OBs? OR How do I organize my program flow?

The program flow is regulated differently in CoDeSys than in Step7. Instead of OBs, there is the block type "Program". This is the top level, so to speak. Programs can call each other or be called by FBs, but not as an instance. They have their own memory area in which instances of FBs can be stored, for example. These values are retained from call to call. Programs are known globally.

Programs can now be called event-driven or cyclically. You can call up one or more programs in an M-PLC project. To configure this, go to the "Resources" tab at the bottom left of the navigation area in the M-PLC. You will then see an item "Task configuration". If you open this item, you will see the "DefaultTask" configured there. You can add further tasks to this if you wish.
The priority that can be set here differs from the priority on the controller. Although they correlate, they are granular in different ways: The priority in M-PLC can be set between 0..31. This is converted to the control priority 18...175, which ranges from 0...255 in real terms. The higher the number, the lower the priority. The quivalent of the control priority is displayed at the bottom of the window when it is changed. The default is 19.
Below this, you can set the call type:

• Cyclical: The task is called at a fixed time interval (comparable with wake-up OBs in Step7). However, it must also be able to be processed within this time frame.
• Free-running: The task is processed and called up again immediately - but with the lowest priority. This is comparable to OB1 in Step7.
• External event-controlled: Various events (errors, events, sync signals) can be selected here. Comparable to error or event OBs in Step7.

The process image can be switched off via "Deactivate PI".

go to top...

---

Where is my HWConfig? OR How do I configure my hardware?

There is no hardware configuration as in Step7 - certainly not as convenient.
The configuration is already taken from the hardware when the station is ready. The online device automatically determines the connected hardware. You can then configure this further.
You can either work live with the online device or set up an offline device on the large table.
The advantage of the online device is that you can see all the effects directly and configure the device straight away. In many cases this is an advantage, as hardware or variables often have to be imported directly from the device.
The disadvantage is that the configuration may take quite a long time, as restarts are often necessary for changes to be accepted.
The offline device is configured and can then be "deployed" later, i.e. installed on the corresponding device. If you need the hardware configuration in M-PLC, it must be exported and imported there. With the online device, it is simply read out.

The biggest disadvantage from my point of view is that there are only comprehensible wizards for a few actions. The user is left to his wealth of experience (which has to be gathered first) and, for larger configurations, to his own configuration tools. Although everything can be configured via the Solution Center, if you have 100 signals to transmit, for example, this painstaking work becomes a matter of nerves - because each signal has to be entered individually by hand. On the other hand, the system has the advantage that the configuration is saved in a human-readable text file. This means that even the largest configuration can be created via Excel and simply copied into the file. Of course, the pitfalls of the syntax must be taken into account. Otherwise, everything looks correct, is even displayed correctly in the Solution Center configuration dialog under certain circumstances, but is still ignored by the interpreter when the controller is started - without an error message.

go to top...

---

What are the rotary switches on the control unit for?

The CPU has two rotary switches, the lower one is the "High" switch, the upper one is the "Low" switch.
These have the following meaning:






Notes:

• Test mode: if the processor module has forgotten all parameters (could happen in the past when there was still battery-buffered NVRAM0), all necessary parameters for the recovery can be entered in the console in this mode.
• In test field mode, the controllers in climate chambers are connected to central computers via COM1 in order to request test programs, reboots, measurement data and reports from the controller.
• Boot mode F4 and F5 do not differ.

go to top...

---

Differences between Virtual and VirtualRW

If cards are set to Virtual, real hardware is simulated. Inputs cannot be written/forced with either the PLC software or the Solution Center.
If cards are set to VirtualRW, real hardware is simulated. Inputs can be written/forced both with the PLC software and with the Solution Center for test purposes.

If real hardware is found, the mode of the card is automatically switched to real. This means that robust systems can also be set up in which defective cards can be removed but the program continues to run. However, missing/defective cards cannot be detected.

go to top...

---

The interfaces

There are some standard interfaces, which I would like to briefly highlight here:

The control units have up to three Ethernet interfaces. Unlike Siemens, these are actually independent interfaces and are not "switched". The advantage: Several independent networks can be set up. The disadvantage: Looping through the Ethernet á la "In/Out" is not supported. Either the data traffic must be explicitly routed from one interface to the other (which, as far as I know, only works via a separate program) or all controllers must be connected to each other in a star configuration via one (or more) switches.

The control units also have an active USB-A socket that can be used to connect storage media. These can be used for a wide variety of purposes, for example

• Updates
• Backups
• Data transmission
• Memory expansion
• Replacement of the internal memory
• Emergency boot medium

The last point in particular becomes interesting if you come across an unknown system or have an unknown control unit in your hands. The IP is often unknown. If you have a USB stick with a configuration file ready, you can boot from it (the operating system can be on the stick or loaded from the device) and view the configuration file of the device - and thus read out the IP. Test scenarios can also be carried out quickly: Copy the internal memory of the control unit to the USB stick, copy the software to be tested to the stick and set the stick as the boot medium. You can then test your new program without changing the original version on the control unit. If something goes wrong or the test is finished, reset the rotary switch, remove the USB stick and the old program will run again.
Newer control units also have a USB mini-B socket for direct connection of the control unit to a programming device. With newer controllers, it is no longer necessary to know the IP in order to connect to a device. The only question here is whether the decision to use a mini-B socket was better than a normal type B socket, considering the sometimes harsh environmental conditions in which controllers are used.

There are usually two serial interfaces on the devices. The first is permanently set to RS232. The console is read out to this as standard, so that errors can be read out directly here via a terminal in the event of serious problems. The second interface can be switched between RS232/RS422/RS485. Switching is also possible from within a program, so that the interface can be "switched off" by switching the topology (as different pins are connected). The communication of the interfaces takes place in the higher-level operating system, so that the buffer must be read out regularly by the program. The operating system itself does not provide a "New Data" indicator.

Some control units also have a CAN interface.

go to top...

---

What are station numbers for?

A station's backplane bus can manage a maximum of 16 modules. If this number of modules is to be increased or if the backplane bus is to be extended, whereby the bus rails are more than 10 cm apart, a station can be extended using a fast bus.
This requires a fast bus master and a fast bus slave. The fastbus master in turn has its own power supply to supply its backplane bus.
This extension would then be station 2.

go to top...

---

Numbering of the cards

A card number is possible from 1...32000. The number of a card within this range is arbitrary, but must be unique within a CPU.
The card numbers apply to both real (hardware) cards and virtual (software/bus/communication) cards.
This allows you to create certain categories within the company.
For example, the following categorization can be thought of:
A card number is structured as follows: XyyZZ

• X
  • Not available: Hardware card (I/O or interface module)
  • 1 = Virtual card for the transmission of peripheral data
  • 2 = Modbus master card
  • 3 = Virtual card for the transmission of Modbus data
• yy
  • Not available: Hardware card (I/O or interface module)
  • 2 digits: Number of the substation (slave number)
• ZZ
  • 2 digits: consecutive card number on the slave (both hardware and software cards)

Example 1:
The IO card on slave no. 2 in slot 3 can be called card 3.
The associated communication card (virtual) would then be called 10203 (both on the slave and on the master).


Example 2:
The Modbus card on slave 3 communicates with Modbus slave 50. It has the number 20350.
The associated communication card (virtual) is then called 30350 (both on the slave and on the master).


This scheme can of course be adapted for every company and is only an example of how the number of card numbers can be used sensibly.
go to top...

---

Numbering of the slots

The slot numbers are specified for each card, but are not used or checked for Modbus or BCH cards; they can be specified as required. It can be assumed that other virtual cards do not use the slot number either. In this case, it would only be relevant for hardware cards whose slot it specifies.

go to top...

---

Counter

Special functions, such as counter functions, can be activated on some DIO cards.
If a counter function is activated, additional analog channels are activated at the end of the card, on which the counter reading can be retrieved (read) and set (write).
The counter reading is represented as a DINT, i.e. it counts up to 2147483647. After this, a transition to -2147483647 occurs.
The maximum pulse frequency is 20kHz, the pulse length must not be less than 33µs.
A counter has several inputs for additional functions: Reset, metering direction, ...
Some of these inputs can be used for normal DI functions, provided they are not required for the function of the meter. See the documentation for the modules.

go to top...

---

How do I let multiple tasks communicate with each other?

If you have programmed several tasks, it often happens that they have to exchange a bigger amount of data with each other. There are two ways to do this. Either via GDs, which are general memory areas in the controller that are shared by all tasks (comparable to flags in Step 7). Or you can go the high-level language route: via pointers.
I would like to briefly explain this last method here.
The idea is that you store the data in a task and then access it from another task. The best way to do this is to create a user-defined data type (Step7: UDT). This is made known in both programs. Let's call it "PubData".
In one task, create a global variable of the type PubData and read and write to it as normal. Now create a pointer to this variable. Important: This pointer must be published as an SVI variable.
Now create a pointer of type PubData in the other task. Initially, this pointer has the value NULL.
The first thing the program should do when starting up is to get a value for this pointer, namely the address at which the data is stored in the first task.
This requires several steps:

• SMI_Connect_NB is used to establish a connection to the CPU. If you enter -1 for the IP here, you will receive a connection ID to the local CPU. However, a connection can also be established to any CPU in the network. This also allows communication channels to be established between CPUs.
  It is important to use the command with the ending _NB. NB stands for "Non Blocking". This means that the program sequence is not blocked. The function is called and queried again in each cycle to see whether a result is already available. Neither the program nor system resources are blocked.
• Now use SMI_GetAddr to get the address at which the pointer to PubData is located.
• If this is successful, use SMI_GetVal to read the value of the pointer and check that it is not NULL.

All functions are defined in the SMI_plc.lib library. Bachmann offers the SVI_comfort library for easy handling.
This ensures that the first task is running and is already writing valid values. Otherwise the pointer will still contain NULL and will not be evaluated.
Now you have a valid pointer in the second task and can access the values directly using the dereferencing operator ^. For example like this: MyPointerToPubData^.MyValue.
Care must be taken when the first task is stopped or updated. This can lead to unforeseen consequences. Otherwise, this method works perfectly.

go to top...

---

What are BCH/BCR/BCP?

Bluecom (BC) is the basis of redundancy at Bachmann. This is available in two different expansion stages: Network redundancy and hot standby redundancy.
The basis for network redundancy is the BCP, the Bluecom protocol. It realizes the redundancy mechanisms and the voting of which connection is used at network level.
For the user, the BCH, the Bluecom handler, is the interface to the BCR. Virtual cards with channels for data transmission are defined in the BCH. The BCH therefore takes on the role of the data organizer.
If hot standby redundancy of two controllers is required, the BCR, Bluecom Redundancy, comes into play. This is responsible for ensuring that the data from the two controllers is synchronized with each other. For this purpose, a BCR channel is set up for the task to be synchronized. This channel is up to 1440 bytes in size and synchronizes the task data stored in it on both controllers. If it has to do this over several cycles because permanently different values are produced in both tasks, the controller drops out of redundancy. By default, all variables of the task are in the redundancy channel, unless they are marked as REDUEX. However, they are still counted when determining the size of the channel, which means that no redundant task larger than 1440 bytes can be created.
However, up to three tasks can be kept redundant, i.e. 3x 1440 bytes = 4320 bytes.
In order to be able to use the hot standby redundancy, special functions for times and counters must be used which are compatible with the redundancy. These are stored in the BCR_plc.lib.

go to top...

---

Calculate the size of a BCH card.

Add up the size of all DO channels (U1/Bool counts as bytes!) and round up to a multiple of 4, add 8 bytes = output packet size
Add up the size of all DI channels (U1/Bool counts as bytes!) and round up to a multiple of 4, add 8 bytes = input packet size
Input packet size slave = output packet size master
Outgoing packet size slave = incoming packet size master

If the 8 bytes are not added, the following error message may appear: BCH_CREATETRAILER: Input length of 'local:SlaveXXX' too short for trailer!.

There is a console command for diagnostics:

bch_ShowCard(CardNb)
This outputs the configured and used lengths (e.g. "LengthIn: 100 (used 12)")
The 8 bytes for the BCH must be added to the "used" length!

The 1400 bytes that can be specified in the BCP do not refer to a segment, this is the maximum data length per slave.
There is a common configuration in the segment, which then applies to all slaves, but this is not a limitation for the segment, but for the individual slaves.

go to top...

---

Difference between bch_DoCmd and bcr_UpdatePi

The doCmd only updates the process image in the BCH. The hot standby redundancy (BCR) is not updated. This can lead to unexpected and undesirable results. For this reason, bcr_UpdatePi should always be used in fully redundant operation, as it also updates the redundancy channels.

Conversely, bcr_UpdatePi must not be used for network-redundant systems, as there is no BCR here. This will result in extremely slow updates on the BCH. In this case, bch_DoCmd must be used.

go to top...

---

MaxCycleTime

The MaxCycleTime defines the time after which the task looks for new data in the communication buffer. The MaxCycleTime must be adjusted depending on the baud rate. If this is too long, it is entered in the logbook, as the task checks for new data too rarely and compliant communication cannot take place.
For the on-board interfaces, the keyword COM[COM-Port]MaxCycle is used, MaxCycle is therefore set per port.
For the RS204 card, the keyword MaxCycle is used, MaxCycle is therefore set module-wide for all 4 ports.

Recommended values for MaxCycle:




go to top...

---

Modbus addressing

Modbus groups different data types: Digital values = coils (read/write) and analog values = registers (read/write). The telegram functions 03H and 10H, for example, use register addresses from 40001. The data type 4xxxx is already given by the telegram function used.
The 4 is therefore omitted in the telegram and the data type is usually not specified in the Modbus descriptions.

Another special feature of the Modbus telegram is that the numbering of the registers starts at 1, but the addressing starts at 0.
So, for example, when reading register 40001, address 0 is requested in the telegram.

Coil/Register Numbers	Modbus address	Data address	Type	Description
1-9999	0-9998	0000 bis 270E	Read-Write	Single output coils
10001-19999	10000-19998	0000 bis 270E	Read-Only	Individual input coils
30001-39999	30000-39998	0000 bis 270E	Read-Only	Analog input registers
40001-49999	40000-49998	0000 bis 270E	Read-Write	Analog output holding registers

Coil or register numbers can be thought of as memory location names, as they do not exist in the actual telegrams. The data addresses are used there.

For example, the first holding register, number 40001, has the data address 0.
The difference between these two values is the offset.
Each data type has an offset: 1, 10001, 30001 and 40001.

• Register 1 (Coil 1) = Modbus address Coil0_1 (Bachmann / master) or Modbus[0] for a slave mapping CoilsSviList to the array of BOOL Modbus[0..x].
  
• Register 40001 (HReg 1) = Modbus address HReg0_1 (Bachmann / master) or Modbus[0] for a slave mapping HRegsSviList to the array of UInt Modbus[0..x].

.
go to top...

---

Consistent transmission of all data

Some Modbus slaves require all data to be transmitted consistently, i.e. all data must always be transmitted in one go.
There are several ways of doing this:

• Flash a small offset for each value so that a constant change takes place
• There is the DoCmd MIO_CMD_SENMBMESSAGE. Here you have to do everything yourself, but you can determine when and what you want to send.
• Use the Mio_DoCmd8_NB function block. This function can be used to write HReg data cyclically from an array. The maximum length specified in the standard can be written cyclically here. Even values that have not been changed.
• Place all data in one channel: Channel1 = "MyArray/ARRAY(16)/rwps/HReg0_8". Then (!) all data should be transferred consistently as they are in one channel.
  • The array is always an array of bytes, the HRegs are words.
  • Imported into M-PLC, a further view of the data area can be set up using the keyword AT.
  • Only works with arrays up to max. 128, i.e. for 64 integers.

According to the Bachmann manual:
To keep the number of queries (requests) and therefore bus accesses as low as possible, these are grouped together. All channels that have the same read or write flags (r, w) set and access the same or neighboring addresses in the same address range (Coil, HReg, Disc, IReg) are combined into one request.
Channels that have been defined as individual requests (SCoil and SHReg) are not combined with other channels. If optional parameters are not specified, default values are used for these parameters. These queries are therefore also combined.

If channels are not combined, data inconsistency may occur, particularly in the case of writeable channels with overlapping Modbus server data address ranges.

The summary is also carried out across modules if:

• The configuration setting CombReqOfCard = TRUE is set for the Modbus-UFB module
• Several Modbus master UFB modules have been configured for a physical slave device. The system recognizes this status as follows:
  • For Modbus RTU:
    • The modules have the same slave address (keyword SlaveAdr)
  • For Modbus TCP:
    • The modules have the same slave IP address (keyword SlaveIP)
    • The modules have the same destination port (keyword PortNb)
    • The modules have the same optional slave address (keyword SlaveAdrGateway)
• If optional parameters are not specified, default values are used for these parameters. These queries are therefore also summarized.

Fazit:

As soon as a value in the process image changes, the entire Modbus is transmitted (see summary of requests above).
If necessary, the polling rate of the interface must be adjusted to the change cycle of the variable (e.g. for a counter or a flashing bit).
Example: Counter changes every second, polling rate set to 1500ms.

If this is not the case, the values must be written with mio_setValue, bypassing the process image. The Modbus channels then recognize that they have been written and send their data.

go to top...

---

SyncWithNet

The SynchWithNet parameter was implemented specifically for the use of Modbus rings. For this purpose, a Modbus ring is physically set up and connected to two neighboring interfaces (e.g. on an RS204 module). A NetNB is then configured for each interface. The optional SynchWithNet parameter is now activated for the first interface and set to the NetNB number of the second interface.
The interfaces are now switched alternately active and inactive, always after a slave query has been run. The data is available as normal for each interface individually afterwards (i.e. the Modbus modules must also be configured twice for each slave). The timeouts can now be used to determine whether a slave can be reached via both interfaces (ring OK) or only via one interface (ring stopped). It is now possible to react accordingly. This implementation is left to the programmer.

go to top...

---

BCH

go to top...

---

BCR / Redundancy

go to top...

---

Modbus

go to top...

---

Upload .m from M-PLC fails: File not found

It may happen that the upload of the program file to the controller fails because the path or the file is not found.
In this case, M-PLC may not find the correct path. Under communication settings, enter the absolute path instead of the relative path:
relative path: app/
absolute path: /cfc0/app

go to top...

---

Problems with the FTP connection

A debug output of all FTP commands to the console can be activated:

• Open console in the SolutionCenter
• cExecute ftpdDebug=1
• All FTP commands are now output to the console when a file is uploaded from M-PLC, for example.
• switch off the output again with ftpdDebug=0

go to top...

---