Save File Dialog


Recommended Posts

  • 6 months later...
  • 7 months later...

Hi,

I just tested the latest DF version and it's not fixed.  It still says "no items match your search" as per the first image i posted. The file extension matches the extension of other files in that folder but none are being displayed. Like I showed before it works with the load but not the save.

Also, have you changed modbus recently in newer versions? I was using the arduino modbus library modbusino and reading unsigned 16bit integers into DF fine and now I just get "illegal type" message. My punishment it seems for upgrading and the bug wasn't even fixed!  

cheers

Link to comment
Share on other sites

I will look at that again now.

As for the second part, no we have not changed our Modbus implementation is many, many years.  I'm guessing you changed something on the arduino side, or changed tag (channel) #'s at the same time as you upgraded and are making the wrong connection.  Illegal type error would come from the slave.

 

Link to comment
Share on other sites

OK, I looked at it.  The bug is in fact fixed.  The issue is the function call.  You are specifying ".meth".  That will only give you files that are exactly ".meth".  Not "a.meth" or "b.meth", only ".meth".  You need a wildcard on the part before the period, so "*.meth", just like you would in Explorer.  

FYI: Both the open and save dialogs are standard windows boxes and completely handled by windows.  The open dialog is handled by the function "GetOpenFileName", while the save one is handled by "GetSaveFileName".  You can google these and read about them on the msdn.microsoft.com site.  The bug we fixed simply had to do with a typo in what we were passing to these functions.  How the functions perform based on the input is determined by windows so I can't say why ".meth" might work in the Load version and not the Save version.  It may be that you put * in your script there, but forgot it in the Save version and just didn't notice it.

Link to comment
Share on other sites

oops, yep, I missed the * on the save but not on the load! thanks

I'll check the modbus again, I read in one of your other replies that it hadn't changed for years and I wouldn't expect it to as it's a standard, but I literally just upgraded and it stopped working. I think the drop down modbus options have changed in the channels though as now it has readholding U/S16 but when calling the device in script it just says S16, I guess these are the same anyway and the modbus underneath hasn't changed but maybe the way it is written has? I don't know why this matters, it probably doesn't but maybe it's just confused me somehow as something looks different. I'll go back to basics on my setup and see what's happening.

Also, out of interest, what is the number in brackets after the modbus call type? some of the options are duplicate but this number changes.

cheers

Link to comment
Share on other sites

Its which Modbus function code is used.  Some devices only support certain function codes, so for example, they may only support the function for setting multiple registers, and not the one for single registers, so if you want to set a single register you still have to use the multiple register function version.

Link to comment
Share on other sites

  • 2 weeks later...

thanks, so the difference between the command type setregisterS16 (6) and setregisterS16 (16), is the latter actually being set multiple registers.

It was this that was causing problems as the arduino library modbusino needs the (16) command even to set a single register.

I found a previous AzeoTech post which summed it up nicely, and quote it here in case anyone else has this problem:

Quote

 

The problem is that your port monitoring software is using the 16 command "Set Multiple Registers" even when it wants to set a single register. This is sometimes seen when the programmer is lazy, though usually its on the device side, which might only support 16 or 6. Command 6 is "Set Single Register" and therefore does not have to specify how many words are being set. So, looking at these two:

S16 01 06 75 7F 00 D2 22 43

S32 01 10 75 7F 00 02 04 00 D2 00 00 4E 60

The command for S16 is 6, set single register. Its setting the value to 00D2. Note that this comes immediately after the address. For S32, it takes two words to set a 32 bit value, so DAQFactory has to use the 16 command (or 10 hex as your data shows). In this case, the two bytes after 75 7F, the 00 02 are the number of registers to set, in this case 2. It then passes the two values, 00D2 and 0000, which make up a 32 bit value of 000000D2.

This same thing applies to all the floating point choices. You see that U16 also uses command 6.

So, the bottom line is that the software that you are referencing too is actually incorrect. If your device only supports command 16, even when setting a single register, then use the S16 (16) I/O type. This is why we have two Set Register S16 I/O types. One uses the normal 6 command, and the other allows you to force DAQFactory to use 16 for devices that don't support it. Note that the function SetRegisterS16() will use 6 if you specify one value, and 16 if you specify more than one.

In addition, in your example when you use:

Device.MyDevice.SetRegisterS32(1,30079,{0,210})

You are actually setting 4 registers. You have two values, 0 and 210, but you are specifying these as 32 bit values (S32), which take 2 registers per value, so 4 total registers.

 

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.