Topics created by robl

Yes! So obvious when you see it! Thanks :)

Looking at the debug output, the rand block is running all the time, even though it is only needed to generate one number at a time. I am not sure if this wastes CPU, or if it is more efficient to only enable it when triggered, and turn it off again once the number has been generated. What do you think?

I took your logic and made it behave like TON but with a random time (so, the output of my timer will go in to this, then the output of this will be delayed by some random time, so the result would be, the light will come with a random delay of on up to an hour after 6PM, or whenever the time is set by the timer.)

0_1551792302630_3ecdb6f0-e147-47fb-9db0-2e1af24c04db-image.png

(This first turns on the rand -> integer sequence for 1s, then after 1s, TON_0 switches on to capture number and to activate the actual switch on delay)

0_1559909211138_034debcb-00d8-4f0f-bf32-e2f79989f461-image.png

Problem seems to be triggered when replacing an existing function with a similar function, then any new vars stop working, any changed vars stop working, and the function stops returning any output even though it's getting everything valid input.

Hello @robl,
thanks for such detailed answer.

I understand your frustration with the HMI. The complications you are facing are based on the Finite-state machine design of the Mervis, which was picked for easier transition from other/older PLC systems. Realization of some complex logic is not as straightforward as you are probably used to from other programming languages / paradigms.

I would love to dive into your problem with controlling outputs from program and HMI:) I have a solution which was primarily design for our Direct Switch functionality, but it needs a serious documentation because it is quite complicated. I hope I could be able to put it together by the end of this month.

As for the Evok - we are finishing with Node-RED nodes for UniPi which internally use Evok. Here are some quick mockups of how it will be used:

Basic usage of all inputs and outputs:
0_1547729051184_4c902d82-5ff2-4bb8-a92d-b670be9ec61f-image.png

Some basic regulation of heating with hysteresis:
0_1547729093749_4cb64d0e-b55b-4fe5-a314-97b1c0d39102-image.png

Generic Node-RED Dashboard:
0_1547729157499_4f755ae4-22f0-4d0d-ba2f-54195ea9f234-image.png

It's all in the process:) If nothing bad happens, we will release it by the and of this month.

Best regards,
Martin

Yeah, what I mean is, I first downloaded the configuration, saw that the setting was already 0, and then just uploaded it again. I didn't actually change anything in between. Anyway, seems to have now got it set correctly. Thanks for the help!

The multiple interfaces problem is odd, since the two interfaces are NOT both connected at the same time. eth0 was just set to DHCP and not connected, but the wlan0 interface only works properly when eth0 is plugged in. If eth0 is unplugged, the wlan interface works for a while but then eventually stops working properly.

This seems to be a Raspberry Pi issue people are reporting elsewhere, though not easy to debug as the unipi display port isn't accessible to connect, so it's hard to see exactly what's going wrong. (Maybe I will take the SD card and boot it in a regular Raspberry PI with a display connected, so I can better understand what is going on.)

The issue would seem to be a combination of the default ARP behaviour in Linux which responds with the wrong MAC address, DHCP, and that when there is no cable connected, in some situations Raspberry Pi still thinks it's up and tries to use eth0 anyway. (/etc/interfaces "auto eth0" vs. "allow-hotplug eth0")

So far, I have both interfaces set to dhcp, and I did have "auto eth0" in /etc/network/interfaces but looks like this was causing some of the problems, so I set it back to "allow-hotplug wlan0 eth0". and then set:

/sbin/sysctl net.ipv4.conf.all.arp_ignore=1

Now, when eth0 cable is removed, the interface still shows as "UP" but it deletes the routes and remove the IP config from the interface, and then because it responds to ARP with the correct MAC address for wlan0, it doesn't break.

Also set "wireless-power off" under the wlan0 interface config, but not sure if that made any difference. It would seem that some wireless APs are able to send a magic APSD request which causes the interface to go into power save mode. I don't think my AP does this.

I'll see how I get on. Worst case, I will have to just add commands to toggle eth0 down when wlan0 comes up, and toggle eth0 up again when wlan0 goes down, called from up / down hooks in /etc/network/interfaces.

@tomas_hora I'm not sure that made any difference.

I have to do some more testing, (For some reason the IDE has been crashing on me a lot when I try to do certain things like delete outputs or function blocks.) but what I think is happening is that the correct logic is being uploaded to the PLC, but the "debug" output (e.g. when using manual mode switches) loses track of things after the update.

Exiting and restarting the Mervis IDE, it seems to come back again.

Ah. Seems I just realised where I was going wrong.

I was missing the step to configure the module. Deploying the solution is not enough.

"We just changed the configuration of the PLC modules, which is not applicable by simply uploading the solution. To save the configuration, follow the UniPi - Configure Module tutorial."

In theory it should work the same as any other extension we have, though we cannot guarantee it, since some devices deviate from the standard protocol in one way or another. Either way you will need to create a custom ModBus map, whether you are using Evok, Mervis or something else.