Posts made by Martin Kudláček

Hi @tomkling,
the HW architecture in the Axon is different than in UniPi 1.1 which you probably use as a reference. The ADC in the Axon is connected to the STM32 microcontroller which does the heavy lifting and the measured values are passed via SPI to the main CPU. The software protocol is modified Modbus, which is then translated to the ModbusTCP via unipitcp service. Therefor the fastest way is to talk to the unipitcp.

Since the communication is layered, there will be some slowing down along the way. Keep the requests to the other IO on the same group to as low as possible to speed up the communication. This would be harder to achieve in the Evok, which polls all the IOs all the time.

Best regards,
Martin

Hi @tomkling,
the analog measurements are typically not that fast and the 25ms is more or less the sampling speed in the HW. The best is using the AI on the Group 1 (AI1.1), but measuring resistance is generally slow due to averaging multiple measurements.

You would be able to get better speed using ModbusTCP, since Evok is yet another layer between your SW and the HW.

Best regards,
Martin

@jakubch The reason is probably due to the Mervis solution being created in the "Simple" mode rather than "Full" mode. Here you can learn how to switch to the Full mode to unlock the Autogen functionality: https://kb.unipi.technology/en:sw:01-mervis:creating-new-project-hidden#switching_from_simple_mode_to_full_mode

@havor

Short answer: yes. But it will take time, since we need to change the enclosure as well, due to the changed position of the ethernet and USB.

Hi @r3sist, did you configure the module? It looks like you still have the AI in the voltage mode, hence the low readings.

Hello @r3sist,
for this type of recalculation you can use "transformation". Transformations are built-in functions for recalculating the measured value and you can configure them for each input.

Your sensor outputs 4mA when the pressure is 0 bar nad 20mA when the pressure is 400 bar. You can use transformation "LinearByTwoPoints", via which you define line on the graph by two points: X1, X2, Y1 and Y2.

For first measured value (X1) in mA, you define what value you want (Y1). So for X1 = 4, you want Y1= 0. The same you will do for X2 = 20, Y2 = 400.

Here is where to configure this:

After this configuration, you need to upload the configuration to the module: https://kb.unipi.technology/en:sw:01-mervis:unipi-configure-module-hidden

Best regards,
Martin

Hi @jonffh,
the online PLC values are shown in the "Variable browser". What you are looking at is the definition of the 1-Wire thermometer prototype.

Normally, you should se the "Variable browser" among other tabs like "System status", etc. You probably closed the tab. To reopen it, click on the "View" in top menu and then click on the "Variable Browser".

Best regards,
Martin

Hello @tin-androić,
this is about wiring together the DI and the RO. All of that and much more is describe in our tutorials: https://kb.unipi.technology/en:sw:01-mervis:06-tutorials.

Helo @jos0,
the name "holding register" doesn't mean the value is stored in the non-volatile memory. This is just a type of the data store which comes from the Modbus naming convention, which means it can be read and written into, as oppose to the Input register, which can be only read.

You can save the current value of the counter register with the saving of the current values to internal flash. This save can be initiated by e.g. setting the coil named "Save current configuration and use on startup" which has to be called on the appropriate group.

We do not recommend to do it very often as this will corrupt the internal memory. Try solving the problem in the program instead.

Best regards,
Martin

Hello @jos0,
the counters are reset after reboot. More precisly, they are reset when the PLC loses power. They survive when the OS inside of the PLC is rebooted.

Hi @derinex,
to attach to the PLC via IP and port is a bit confusing.

First, attach manually by filling the IP, port and the model of the PLC
Then proceed with attaching via "Use deploy parameters"

After that, you should have the PLC fully attached.

Best regards,
Martin

Hello @ayone0518,
you need to pull 32bit data, so you have to define element which spans over 2 registers. This is done via the Multibyte Length property, which you have to set to 4 (4 bytes = 32 bits)

If it is possible, I would suggest to turn the communication around. Make the Mervis a Modbus Slave (server) and the Weintek Modbus Master. Configuration in the Mervis will be much easier. Try following this tutorial: https://kb.unipi.technology/en:sw:01-mervis:setting-modbus-server-hidden and here you can see how to set it against Weintek: https://kb.unipi.technology/en:sw:01-mervis:weintek-ip-series-hidden#setting_up_the_unipi_for_sharing_temperature_and_relay_output

Best regards,
Martin

Hi @dickesc,
simply - you cannot. But I think you are trying to somehow get the information about the failed communication, is that correct?

If so, each Modbus group of elements has so called "attributes", which are special variables, which for example tell you when the last communication occured, and what is the last state of the communication exchange:

What you are probably looking for is the _commerror variable. When true, the current value in all the elements is not correct, since the communication is broken. If false, the values are correct.

Include this _commerror variables into your program to detect and work around the communication errors.

Best regards,
Martin

Hello @jakub, the pin header of the Raspberry Pi inside of the Neuron is not accessible and there is no space inside of the Neuron for such additional devices.

Hello @dickesc,
just change the input parameters "subject" and "message". Those are string variables, which you can dynamically fill/construct with FUPLA blocks from the "Basic String Boxes".

You need to convert the values (bool, integer, real,...) to string first with block called "to_string". Then you can put together multiple strings with "concat".

Best regards,

Hi @dickesc,
you just did everything you can to fix this - you made a detailed report. I am forwarding this to the developers to have it fixed.

Thank you for your contribution,
Martin

Hello @søren-hedegaard-0,
you didn't pass any input value to the ph_control_hourly(), so the block doesn't know anything about run_at_time and ph_hourly_feed.

The call should look this:

ph_control_hourly(run_at_time := local_run_at_time, ph_hourly_feed := local_ph_hourly_feed, out => local_out_value)

If you look in to the help (F1) of any built-in FB, you will see a usage and you learn how the ST works:

Best regards,
Martin

Hello @valtert,
the description on the page is misleading. The real situation is this:

Analog output on Group 1 is capable of outputing 0-10V, 0-20mA and measuring resistance up to 100kOhm
Analog outputs on Group 2 and 3 and on the extensions are only capable of outputing 0-10V

Same goes for Neuron and Axon product line. If you need second AO in current mode for your project, you have two options:

• add a second PLC as a "dumb" extension and communicate with the master PLC via ModbusRTU, ModbusTCP or SSCP
• purchase a 3rd party ModbusRTU IO module, such as this: https://www.advantech.com/products/gf-5vtd/adam-4024/mod_5e18f39b-38ef-4033-98f9-1ede917139ee

I am sorry for the incovenience, we will fix the product description shortly.

Best regards,
Martin

Hello @valtert,
the AOs on group 2 and 3 and on the extensions are only capable of voltage output. Can you please show me, where is the specification you mentioned? It needs to be corrected.

Thank you,
Martin

Hi @knebb,
definitely not. The DOs are NPN type (open collector). You can read more about how to read the NPN outputs with digital inputs here: https://forum.unipi.technology/topic/712/neuron-12v-digital-input/2

Best regards,
Martin