burt4munger

Okay, thanks -- we had already considered splitting the string as a workaround but figured we would check first to see if there was another approach, so now we will proceed with that!

Hi, We are trying to use the FromJSON() function on an object to read in the results from an API and utilize the data in DAQFactory. The data is in the form of an array of results (example below): [ { "time": 1689202773000, "frequency": 0, "temperature": 24.113449096679688, "density": 1.0002 }, { "time": 1689204584000, "frequency": 0, "temperature": 23.971923828125, "density": 1.0003 }, { "time": 1689206446000, "frequency": 0, "temperature": 23.421836853027344, "density": 1.0004 }, { "time": 1689207479000, "frequency": 1376.7645263671875, "temperature": 23.03997802734375, "density": 1.0013 } ] So far whenever we try to apply FromJSON() on this sort of an array of data, DAQFactory exits immediately (the Windows Application event log records it as "Faulting module name: ntdll.dll, version: 10.0.19041.3155"). If we run FromJSON() on just one of the individual results by pulling it out of the array, it works and we can view the properties. I know everything is an array in DAQFactory, but is there something special we have to do to get FromJSON() to work with a JSON array? (This is in DAQFactory 19.1 Build 2366.) Thanks!

Thank you this resolved the issue!

also while I have seen this before I am presently using DAQFactory version 19.1 2366 on an up-to-date windows 10 system. I am communicating with MODBUS RTU 8-N-1 via RS485 to Automation Direct PLCs and GS2 and GS20 series VFD motor controllers.

oh a typo in the post, should be after that, the first one fails device.quad.ReadHoldingFloat(100, 28673,1) (not reading the U16 as shown in the post) with this error:P-ModbusRTU 0002: Illegal Data Address: LoopQuadMain Line 220 in PLCSteamuntil daqfactory is restarted

new post: these work device.quad.ReadHoldingFloat(100, 28673,1) device.quad.readHoldingU16(27, 4,1) then this works device.quad.readholdingu16(50, 42305,1) after that, the first one fails device.quad.readholdingu16(100, 28673,1) with this error: P-ModbusRTU 0002: Illegal Data Address: LoopQuadMain Line 220 in PLCSteam until daqfactory is restarted I need to be able to read both devices, the read 50002 first trick seems to make no difference. What should I do? old post: So i have read and understand the various permutations on modbus addressing, that is, 0 based, 30-40000, and 50000+ (i am ignoring the 400001 ones). My system has 5 or 6 modbus devices from different manufacturers, and I have had DAQFactory using some 42006 kinds of addresses, where I think it is subtracting stripping the 4 and subtracting 1 before it sends the address down the wire, and all was well. Now, I have a device that seems intent on wanting the 0 based addressing, and fails access to any any addresses until I use the "write to a modbus address over 50000" trick to force the scheme back to a 0 index approach...then the new device works fine, but all the other addresses are now off by one. I really don't want to have to go and find all the locations that specify modbus address constants and subtract one from them, because i will have to go back and test each and every different system to make sure it still works. Is there an explicit control of the scheme, so that I can specify which address mode to use for a given device access? What i see now is even for testing, if I read an address over 50000, the mode changes to 0 index, all the prior devices begin to fail, and the only way to change it back is to restart the program. this fails, until I read an address over 50000, then this works fine, but other addresses like 42006 start failing ?device.plc1.ReadHoldingFloat(17,28673,1) P-ModbusRTU 0002: Illegal Data Address

Ah, this will work great! Thank you!

So i have read and understand the various permutations on modbus addressing, that is, 0 based, 30-40000, and 50000+ (i am ignoring the 400001 ones). My system has 5 or 6 modbus devices from different manufacturers, and I have had DAQFactory using some 42006 kinds of addresses, where I think it is subtracting stripping the 4 and subtracting 1 before it sends the address down the wire, and all was well. Now, I have a device that seems intent on wanting the 0 based addressing, and fails access to any any addresses until I use the "write to a modbus address over 50000" trick to force the scheme back to a 0 index approach...then the new device works fine, but all the other addresses are now off by one. I really don't want to have to go and find all the locations that specify modbus address constants and subtract one from them, because i will have to go back and test each and every different system to make sure it still works. Is there an explicit control of the scheme, so that I can specify which address mode to use for a given device access? What i see now is even for testing, if I read an address over 50000, the mode changes to 0 index, all the prior devices begin to fail, and the only way to change it back is to restart the program. this fails, until I read an address over 50000, then this works fine, but other addresses like 42006 start failing ?device.plc1.ReadHoldingFloat(17,28673,1) P-ModbusRTU 0002: Illegal Data Address

A windows 10 computer I have running two large DAQFactory programs is crashing in about a week due to memory running out and windows crashing (the bluescreen says) The only real applications running are two very large DAQFactory programs (and SQL Server which is known to be a memory hog but i don't think it crashes windows). I suspect the issue is likely something I'm doing, like a db.open without a matching db.close in a fast loop somewhere so I'm already looking for those. Are there any hints where to look or tools built in that might help with this? Has anyone seen issues continuously writing large amounts of debug text to the command window? I looked elsewhere in the forum and there was only one pretty dated article dealing with memory issues.

If you create a component, say a panel, then duplicate it 10 times, group it, duplicate that group a few times, then group the entire thing, and finally ungroup the whole thing, the workspace tree disappears. Moving around a lot of panels on a summary page is a likely use of this feature.