administrators

I must have missed this post somehow.

The most likely cause is that the variable that the channel is mapped to has been optimised out because it is otherwise unused.

Hi Oliver,

I'll try to give answers to what I think your questions are.

Firstly an explanation of channels and register mapping.

When a Modbus Channel is configured in CODEYS the length specified is the number of registers to be read or written using a single modbus command. It is more efficient where possible to read multiple registers in one command, this is both runtime efficiency and efficiency of configuration. It is often more efficient to read larger blocks of registers even if you are only interested in a few of the registers. Having configured the channel to read or write the registers, you can then either map all of the registers in one go into an array somewhere in your application, or map just the selected registers that you are interested in.

All of the registers in a Channel are sent in one command. Each register can be mapped separately or all registers in a channel can be mapped as an array.

One the Neuron there registers are defined in groups, and each of the hardware modules on the Neuron has two groups of registers. The channel Group1A reads all 21 registers for Group1 starting at register address 0, these are then mapped into an array inside the Group1 function block. The function block uses the whole block of registers to determine that communications is good, and also to scale analog values etc.

Secondly to deal with the trigger

Most of the time it is preferable to transfer registers on a cyclic basis, however some actions cannot easily be handled on a cyclic basis, for example resetting the counter. On the Neuron you write a 32 bit reset value for the counter, if this was done periodically it would prevent the counter from counting. The solution to this is to use another VAR to trigger the channel to be sent by MODBUS.

CODESYS actually offers three different trigger modes for channels, cyclic (you can choose the rate), trigger (a BOOL value changing from False to True will cause the channel to be sent, or application (The application triggers the channel). Personally, although I have experimented with the application triggering writes, I prefer to use the rising edge trigger).

The image above shows where the channel called counter is configured to be sent on a trigger. If you then look in the mapping tab you can see how there is a trigger mapped to a boolean inside the Group1 function block. There are also two registers mapped to an array inside the Group1 function block that contains the value the counter is to be reset to.

I hope I have correctly understood your questions. If you have more questions please ask. If the questions are more generic to CODESYS rather than specific to the Neuron I will help, but you may get faster support on the CODESYS forums, there is a large helpful community there.

Hi @OlivierP,

Is there any chance you have changed the SSCP connection username and/or password? Aside from the message "capabilities parsing failed" you should see a message containing "wrong username or password?". If so then you can fix this by replacing the image with the stock one.

If this is not the case, then it would be helpful if you could provide us with some more information, specifically the IDE version, image name and version, and the response for the command "sudo cat /proc/cpuinfo"

@tom84
The mA problem is an issue with older hardware. UniPi Neuron for CODESYS will be updated to resolve the issue at the next service release.

Please note the issue does not occur on current Neurons. No Neuron products shipped since the release of UniPi Neuron for CODESYS will see this problem.

Hi Oliver,

Please see the datasheet which explains how to map the IO for Groups 2 and 3.

In summary you create variables in your application, and then map from the modbus registers directly to these variables. This is the same as for any modbus device in CODESYS. If the datasheet dowsn't help please see the standard CODESYS help for modbus.

Group1 is the same for all Neuron devices, and is more complex, particularly in regard to scaling Analog values. For this reason a function block is automatically created when the device is added. I would appreciate feedback to determine if doing the same for the other groups would be beneficial, or get in the way.

regards David

Hi Oliver,

The POU NeuronL50xGroup1 is a function block automatically created when the IO device for the Neuron is added to the application. It provides easy access to all of the IO and features for Group1, just add the device and then access the IO through the VAR and methods on the function block.

The statements that you have identified are writing to the variables in the function block. these in turn end up mapped to the registers in the channels for the device.

The mechanism of creating channels, and then mapping the values to variables is the standard CODESYS mechanism for modbus devices. UniPi Neuron for CODESYS adds naming for all channels and coils to make this easier. It also adds a function block for Group 1 (which is identical on all Neuron) and performs all of the mapping automatically.

I would be interested in your opinion on this approach of automatically creating a function block with all of the IO mapped. For some users it will be helpful, for others it may not provide what they want. I am considering if I should add the same support for other groups.

For now access to groups 2 and 3 requires you to manually create channels for the IO you wish to access and then map these to VAR in you application. There are some function blocks in the supplied library that may be helpful. This is the same for all CODESYS modbus devices.

There is more detailed help in the datasheet.

@Martin-Kudláček it works, but you have to attach using the "Use deploy parameters" as described a few posts above

Hi @JasperJackson!

There's a couple of ways of doing it, but any solution will probably look similar to yours. The issue is that the HMI does not have internal logic/state, but instead connects directly to the Mervis runtime. We are developing several other non-web HMI solutions, including a phone application and all-in-one industrial displays, which is the primary reason for this.

As such there unfortunately is not a better solution for now, but we'll try and see if we can provide similar functionality anyhow. It probably will not be any time soon though, most likely not in the next Mervis release, which is slated to be out in the next month.

There will however be a very large number of other improvements to the HMI system in the next months release, as it has been a major focus of Mervis development for the past 6 months.

@mikeardy
Consider this as an alternative. I've created 500 holding registers

In my program (it could be ina GVL) I have created an addary of 250 UDINT.

Then I was able to map all of the registers in one go

For generic CODESYS questions I suggest trying https://forum.codesys.com/, for many generic CODESYS questions there will already be an answer posted.

@tom84
That sounds odd, the DAC numbers you mention sound odd to me. So a couple of questions.

What load have you got connected on the output?

I should be able top track back and see what is happening if I can see the values of the Group1 registers. Please post images of the values of the Group1A and Group1B mappings page while the system is running with a known rValue.

If you want me to have a quick look at your application then please contact me via https://www.cososo.co.uk/contact/.