Mywifeisgunnakillme
Valuable Member
Would love to be in your boat.
Terrible Profilux performance
- Thread starter kenchilada
- Start date
- Tagged users None
I have found that if you after a setting back to default ad them once again - all settings will be the same again (however - I do not remember if I had to upload settings and sensor date once again after the re-creation of the virtual sensors. In P3 it is possible to run a virtual copy of the display by GCC. P4 lack this feature - that´s a pity.
With hysteresis of the alarm settings - do you mean a possibility to set different max and low alarm figures on the same probe. That I agree of - it could be nice - but there is workarounds using virtual probes for this
Sincerely Lasse
When I have re-created virtual probes, I do believe the settings restored on thier own.I have found that if you after a setting back to default ad them once again - all settings will be the same again (however - I do not remember if I had to upload settings and sensor date once again after the re-creation of the virtual sensors. In P3 it is possible to run a virtual copy of the display by GCC. P4 lack this feature - that´s a pity.
With hysteresis of the alarm settings - do you mean a possibility to set different max and low alarm figures on the same probe. That I agree of - it could be nice - but there is workarounds using virtual probes for this
Sincerely Lasse
For the alarm hysteresis, let's say your high temperature is set for 80.0F. As soon as temperature drops to 79.9F the alarm will clear. This causes the alarm to cycle in and out many times until the temperature is a hard 80.0F. To prevent this, there should be a setting that doesn't clear the alarm until a set value below the alarm setting, a deadband.
Now I understand what you mean with the alarm. Yes it should be a delay option as it is with the level indicators but also if you can set individual max and min . not plus minus x degree
Edit I think that you can minimize the on/off repeating very much with setting of the signal filter to 1 (strong)
Sincerely Lasse
Kyl
And how does it feel like, to wake up in the sun
I got those gremlins now too, both of my P4 units local webserver settings seem to have been wiped and reset to default - all customization gone, similar to the myghl.com <> phone app issues that some are cursed with. First time that's occurred in nearly 3 years, on both units (P4 / P4E), and occurring within the last 20 hours since they were fine last evening.
I guess the controller gods are punishing me for being somewhat vocal lately about the lagged nature of software updates coming out of GHL land.
I guess the controller gods are punishing me for being somewhat vocal lately about the lagged nature of software updates coming out of GHL land.
This happens when I clean my browser from cookies. I rinse my web browser automatically every time I shut it down. in order to keep my customized local GHL web page - I configure my browser (Chrome) to always allow cookies web data from my local ip address to the local P4 web pages
Another evening of achieving not a lot!
This happens for me when I run an old computer (windows 7) with USB to my P3.1T. to get it to work again - I had to disconnect the USB cable. close and restart GCC. When I use all other PC computers to the same P3.1T - it works without any problems. With P4 and windows 10 it have never happensWith the occasional.......
I think that this is a USB driver problem
Sincerely Lasse
FishyFishFish
Valuable Member
They are errors from attempting WiFi connection. USB works fine.
Never seen this combination with error 50 and TCP/IP conections
However if you configure a new TCP/IP connection in GCC you must first save the command window, close the next and you are back in GCC with the new connection to the left. If you try to start this new tcp/ip connection directly - it will not work. You must first close GCC and restart GCC in order to have this new TCP/IP connection to work. Do not ask me why - but it is this way.
Sincerely Lasse
However if you configure a new TCP/IP connection in GCC you must first save the command window, close the next and you are back in GCC with the new connection to the left. If you try to start this new tcp/ip connection directly - it will not work. You must first close GCC and restart GCC in order to have this new TCP/IP connection to work. Do not ask me why - but it is this way.
Sincerely Lasse
FishyFishFish
Valuable Member
I wish I could say that I haven’t seen this error before but, unfortunately, I have literally seen it hundreds of times.
This isn’t a new connection.
The background to this is that I was trying to set up a new KHD with a new doser. When I tried connect it to WiFi it wouldn't find any networks when I searched for them. I went through the 1980s process of typing it in manually but didn’t get any notification as to whether it had connected or not.
I then added the connection in GCC but it didn’t appear on the device list on the left hand side (although it did show on the admin page of devices).
I then tried to connect to another doser that I already have running, to check the Wi-Fi settings, and those are the errors that I received. This is a doser that has been set up and ‘working’ for several months. I get these errors frequently when trying to connect but, usually, it does connect about 50% of the time so I just keep trying and eventually it works. Last night, I couldn’t get it to connect despite trying for almost an hour. I tried several PC reboots and closing down GCC but nothing helped. Eventually, it just started working again without me changing anything.
Then I had to go back to trying to sort out the original problem of the new KHD doser not connecting. I then had to go through the nause of having to go into the router to see the client list. There, I discovered that it was connected to the router but there was nothing on the device or in GCC that told me that.
Now I had to find out why it wasn’t showing on the device list on the left of the GCC panel. Finally, I discovered that there appears to be a limit to the number of device connections that can be shown on that list. By ‘hiding’ one of the other connections, the new ‘missing’ one appeared.
So now I have the new doser connected. What should have been a 5 minute job took over 2 hours. That still won’t stop the errors that I posted above from coming back again.
Some of this could be my network but maybe not. My Hydros power strip does drop off line a few times a day but it reconnects in seconds. I have no problem with my other Wi-Fi devices.
I have bought a WAP to try to help, and will hopefully set that up at the weekend. I am hoping that will help with the connection issues (but I have no idea if it will or not) but it certainly won’t improve the software.
The wifi chip in the dosers is different from these in P4. The dosers have a RJ45 connection (wired) too.
In a very "electrical dirty" environment I was working with - I use the wired solution for the dosers - it works best. But I have never get error 50 and not possible to connect sign with wifi either on P4 or Doser 2 SA. No possibility to use RJ45 (ethernet) instead for WiFi?
Sincerely Lasse
In a very "electrical dirty" environment I was working with - I use the wired solution for the dosers - it works best. But I have never get error 50 and not possible to connect sign with wifi either on P4 or Doser 2 SA. No possibility to use RJ45 (ethernet) instead for WiFi?
Sincerely Lasse
FishyFishFish
Valuable Member
So the solution to the Wi-Fi devices not connecting by Wi-Fi is to use Ethernet?
I have 2 tanks, both with GHL dosers. They are too far apart from my router to connect via cable (and I shouldn’t have to). I’m not sure my router supports wireless client mode, so I will just have to hope that the WAP on it’s own will help the situation.
But if you’re saying that the problem is with the dosers Wi-Fi chip then that may not help.
I have 2 tanks, both with GHL dosers. They are too far apart from my router to connect via cable (and I shouldn’t have to). I’m not sure my router supports wireless client mode, so I will just have to hope that the WAP on it’s own will help the situation.
But if you’re saying that the problem is with the dosers Wi-Fi chip then that may not help.
In my case the whole system was placed in a small room full of heavy duty electrical devices. They disturb the wiFi with electrical fields rather much. That´s the reason why I use wires. I do not know your situation - just point out that it is possible to use Ethernet.
Have you test to change the response time to 50 000. I read somewhere that it had help in other cases
Sincerely Lasse
