steveandrews Posted January 6, 2016 Share Posted January 6, 2016 Hi, Possibly a bug in the save file dialog box where files with matching extensions are not displayed. Works fine for load file dialog Private.strFileName = file.FileSaveDialog("methodname.meth","C:\ANDREWS_TDU\methods\",".meth","Save TDU method") Link to comment Share on other sites More sharing options...
steveandrews Posted July 8, 2016 Author Share Posted July 8, 2016 Hi, Please could you fix this bug? it's really annoying saving files and not being able to see any files in the save dialog. It works fine for load file dialog so shouldn't be a difficult fix? Cheers Steve Link to comment Share on other sites More sharing options...
AzeoTech Posted July 14, 2016 Share Posted July 14, 2016 OK, fixed. It will be in the next release or email if you want a prerelease. Link to comment Share on other sites More sharing options...
steveandrews Posted March 2, 2017 Author Share Posted March 2, 2017 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 More sharing options...
AzeoTech Posted March 2, 2017 Share Posted March 2, 2017 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 More sharing options...
AzeoTech Posted March 2, 2017 Share Posted March 2, 2017 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 More sharing options...
steveandrews Posted March 3, 2017 Author Share Posted March 3, 2017 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 More sharing options...
AzeoTech Posted March 3, 2017 Share Posted March 3, 2017 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 More sharing options...
steveandrews Posted March 16, 2017 Author Share Posted March 16, 2017 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 More sharing options...
AzeoTech Posted March 16, 2017 Share Posted March 16, 2017 You got it. We created the two versions because some devices require command 16 (set multiple registers) even when you want to set just a single register. Unless your device requires this, though, you should use the (6) version. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.