Messages

1

Support Questions / BasicDataLogger21 write bits as one or zero instead of false or true?

« on: May 02, 2020, 11:19:51 AM »

Did a short search for this, is it possible to change the way the datalogger21 writes the bit status in the data log?  I'm using the ModbusRTUCom1 driver, version 3.99w, Visual Studio 15.9.11

I would like it to write the bit status (address of 0000x) as a 1 or a 0 instead of false or true in the data log .csv file.  In the past I have copied bits to a UI8 data type in the PLC solution (address of 4000x) and this works but I'd rather not need to do that if possible.  Thanks!

2

Open Discussion / Re: Error on New Installation / New Build

« on: April 27, 2019, 07:36:53 PM »

This same error was reported by another user. I also did find it reported by other VS users, so it seems to be some update pushed out by Microsoft:

https://developercommunity.visualstudio.com/content/problem/291761/couldnt-process-file-abcresx-due-to-its-being-in-t.html

My first thought was to delete the resx file by using this process:

The resx file that it is referring to only contains text for a label on the first default form, so it can be deleted:

-   Open MainForm in design view
-   Delete the label in the upper left with the 6 steps on getting started
-   In Soultion Explorer, click the icon for Show All Files
-   In Solution Explorer, expand down MainForm.vb
-   You should now see MainForm.resx and you can delete that file

Just a little update on this in case others have the same problem.  When you delete the MainForm.resx file and you have a basic datalogger21 set up in the file, it breaks it and it has to be rebuilt - there may be other functions that this happens to.  What I finally realized, and it's in the error message- is the problem was the labels Archie mentions on the main form were still in the cs version of the solution - the one I was not using.  Once those are deleted, the solution is saved, then cleaned it will build fine without deleting the whole MainForm.resx file.  Thanks for pointing us in the right direction Archie - we'd all be lost without your help on here!

3

Support Questions / Re: Unhandled Exception: System.ArgumentException: Parameter is not valid.

« on: November 03, 2018, 09:51:44 PM »

I had forgot that the value on the gauge is scaled when I thought it was dropping below the min - it actually wasn't according to a datalog I recorded.  The analog value display is working 100% so far.  Will update to 3.99x or 3.99y at some point and try the Gauge Compact some more.  Thanks for suggestions and the great HMI!

4

Support Questions / Re: Unhandled Exception: System.ArgumentException: Parameter is not valid.

« on: October 31, 2018, 07:04:38 PM »

Ok thanks - The actual value does drop below the negative limits I have set before on the gauge at times.  I'll try making the limits beyond the actual value range and report back tomorrow.

5

Support Questions / Re: Unhandled Exception: System.ArgumentException: Parameter is not valid.

« on: October 31, 2018, 06:51:15 PM »

Correction - I am using 3.99w. 

The min real value can go negative, and I have tried building the gauge to match real (going negative) and leaving the min at zero instead- and get the problem with both.  Does the gauge need to be built with some buffer room (the ability to show below the min and above the max)?  It's a floating value and I have it scaled as well...   Using F4xxxx for the address.  Works fine at least half the time or better I would guess.   I just tried displaying the same address value with just an analog value display instead.  Getting a NaN value at times requiring the restart, but no unhandled exception.   

Thanks very much Archie for any further advice.

6

Support Questions / Unhandled Exception: System.ArgumentException: Parameter is not valid.

« on: October 31, 2018, 06:13:46 PM »

Fairly often I get an unhandled exception error message, along with a white circle and red "X" through my compact gauge.  If I close out the form and reopen, sometimes it takes multiple times, it finally works fine.  Using 3.99w, ModBusRTU.  Driver Log file is attached in case it's helpful, I see the "send" has more data than the "receive" and the data doesn't match, but don't know what that means.  Does the max read group size have anything to do with this perhaps, I have it set at 50 for the log noted as such?  I changed that and the pollrate override to 0 and 5 respectively.  I changed the baud rate on the driver to match on the computer side in my device manager settings.  I'm suspecting it could be the PLC performance, but any other ideas or ways to match the HMI to what the PLC can do?  Thanks!

The full part of the exception text reads:
System.ArgumentException: Parameter is not valid.
   at System.Drawing.Graphics.set_Transform(Matrix value)
   at MfgControl.AdvancedHMI.Controls.MeterCompact.DrawNeedle(Graphics g, Single angle, Int32 cx, Int32 cy)
   at MfgControl.AdvancedHMI.Controls.GaugeCompact.PaintActiveContent(Graphics g)
   at MfgControl.AdvancedHMI.Controls.MeterCompact.OnPaint(PaintEventArgs e)
   at System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer)
   at System.Windows.Forms.Control.WmPaint(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

7

Support Questions / Re: Sign Tool Error: No certificates were found

« on: May 05, 2018, 10:50:18 AM »

Yeah wasn't using publish, just building it, something I have done at least 50 times before.  I found the "Sign the click once manifests" flag was checked in Visual studio (perhaps some windows update changed it, I sure didn't).  Unchecked that (see attached) and it's working again. 

Thanks for the answer anyway Archie!

8

Support Questions / Sign Tool Error: No certificates were found

« on: May 05, 2018, 09:30:42 AM »

I've been using Visual Studio version 17 for several months with no issues, but last night got this error when trying to build:
An error occurred while signing: Failed to sign bin\Debug\app.publish\AdvancedHMI.exe. SignTool Error: No certificates were found that met all the given criteria.         

I thought it may be due to the changes I was making to my project, so went back to an old project and still have the same error. 

Any ideas?   

9

Support Questions / Re: ModbusRTU driver not closing?

« on: June 08, 2017, 06:59:20 PM »

I set that up with 100 ms for pollrate override and it is still strange it seems, it is sending or receiving faster than 100 ms (see attached) and sends and receives at the same time- which is not the case with yours I see.  A few times I see two sends and two receives.

I may have something fouled up in the datalogger properties, I still have it set up to trigger every sample.  I set Log Interval to 0 and pollrate to 100.   I should confirm - I don't need to worry about the interval or pollrate since the trigger is set to every sample?   It sounds like the pollrate override in the driver properties will override anything else so I was assuming the datalogger properties don't matter in regard to pollrate or interval.

You could be right about the plc, to complicate things more it is getting some of it's data via RS-232.  The actual data stream is much more accurate when the datalogger is only set up on the main form, even so after a close look the data recorded by the basicdatalogger21 tool only changes about every 160 ms even though the HMI stamps the log about every 40 ms (when set up to do so), give or take a few 1000ths of a second...

I also logged the driver with a single form set up and it is also attached.  It looks better in that for the most part it alternates send and receive except for the end but still stamps send and receive at the same time.

I think I'll try a different laptop and see if that helps, the one I am using is old with Vista. 

10

Support Questions / Re: ModbusRTU driver not closing?

« on: June 08, 2017, 11:21:23 AM »

Ok, thanks for your help and work on it as you have time. 

11

Support Questions / Re: ModbusRTU driver not closing?

« on: June 07, 2017, 09:24:05 PM »

I am using 3.99w, that's on the first line of the release notes.  During that log I did manage to change forms just before it crashed.  I can send another one staying on the same form if you want me to.

Thanks!

12

Support Questions / Re: ModbusRTU driver not closing?

« on: June 07, 2017, 06:50:35 PM »

Here is one, attached.

13

Support Questions / Re: ModbusRTU driver not closing?

« on: June 07, 2017, 04:35:00 PM »

Yeah I do get a file with quite a few lines.  Will it tell me if both driver instances are active?  I don't have quite enough time to change forms before it crashes so I just assumed it wasn't enough of a log.  Could I change something temporarily just to test?

14

Support Questions / Re: ModbusRTU driver not closing?

« on: June 06, 2017, 08:20:32 PM »

I forgot about that function.  For some reason the app crashes with that enabled- it does log for a few seconds. 

15

Support Questions / Re: ModbusRTU driver not closing?

« on: June 06, 2017, 12:37:08 PM »

Thanks for that suggestion - even though it did not improve things much if any, it obviously was worth a try - I wasn't very confident the way I had it set up was the best way. 

I set up a datalogger in the main page as well and the proof of it disposing after a form change is in the log, still not sure the driver is closing however. 

Is the lack of connection delay when navigating to another form evidence that the driver is not closing?  I looked in my event logs on my computer to see if it was listed- didn't see it but I am no expert looking at those. 

I'll just have to use one form for now until this is solved so it's not too big of a deal, but would be nice to get both forms working.