All Activity
This stream auto-updates
- Today
-
Figured out how to do part of it with the evaluate function, but then realized an array would probably better handle this and then could be used to display data fairly easily in a table element.
- Yesterday
-
That totally makes sense. Is there a way to dynamically read and write multiple variables in the popup? Like set a global variable to "2" when opening the popup and reference that when opening the popup to set the current values and then use it set the values on submit. Basically using a variable within a variable. Quick Sequence code in the Button Component from the main page machine_settings = 2 Page.Machine_Settings.Component.Customer.strContents = Page.Page_0.Component.Cust_Machine_(machinesetting).strText Page.Machine_Settings.PopupModal() Set Channel (from the Edit Box Component) Page.Page_0.Component.Cust_Machine_(machinesetting).strText
-
I'm not a big fan of the edit box in HMI's, so my first suggestion is to consider using a variable value control to display the current settings, and a button next to it that pops up a query for the value. If you really want to use edit boxes, then my second suggestion is to put them in a popup that only updates the filename when the popup is dismissed with an OK button. Putting edit boxes on the primary pages of your HMI is a bad idea, for reasons I explain here: Chances are the issue is that the edit box hasn't lost focus and updated the strContents. You could use the setFocus() function of any other screen element to force the loss of focus, or you can probably do page.myPage.submit()
-
I've setup a quick sequence associated with a button to change the file name based on strings entered in text boxes. For some reason the last character of the last variable in the file name is cut off. Logging.LabJack1.Filename = basedirectory + Page.Page_0.Component.LabJack1Cust.strContents + "_" + Page.Page_0.Component.LabJack1Job.strContents + "_" + Page.Page_0.Component.LabJack1Spec.strContents + ".txt" As as I added variables the 'C' was cutoff, then the '0' and finally the '3' How do I avoid this?
- Last week
-
metaltest joined the community
-
The DAQFactory installation folder is read-only by default unless you run DAQFactory with administrative rights (which is not the same as being logged in as an admin). I am guessing that DAQFactory is unable to save the ddp to its installation folder. I would go into Windows Explorer and change the security settings on the DAQFactory installation folder to allow "Everyone" the ability to write. Keep it this why while you are developing the ddp, then when done revert it back, leaving the ddp file in the installation folder.
-
Hi, I have created a new protocol to help in reading in values from an instrument. The protocol works and I have made sure in the filename I have put the DAQ factory installation directory and that it ends in .dpp. However, after saving if I close DAQ factory the protocol disappears and it doesn't save anywhere. I'm sure its something simple I am missing but I have no idea what I am doing wrong, any help would be greatly appreciated, thanks!
-
fwhite joined the community
- Earlier
-
Unless you can reproduce on a physical port the issue is in the USB driver. Pretty much all those virtual com port drivers use the same core code so have the same issues. DAQFactory uses simple core Windows functions for communicating on the serial port. There isn't much to it as Windows itself takes care of everything. But virtual com ports are really just a trick (hack really) and so aren't particularly reliable. DAQFactory can't bypass them, so we are completely at the mercy of the quirks in the virtual driver. I've been saying for many, many years that people should avoid USB -> serial devices and use Ethernet->Serial if they want true reliability. This is because DAQFactory can connect to the Ethernet->Serial device directly using Windows sockets and not be reliant on some 3rd party driver. Alternatively, though more expensive, is to purchase an industrial computer with native serial ports. There are also other issues with using USB in general in systems that require high reliability, which I can go on and on about, mostly related to the fact that one device can easily crash all the devices on the USB bus. USB is convenient, and for many applications, a failure isn't a problem so we support devices like the LabJack U3 that is USB only. But I would never use a U3 or any other USB device in a case where its failure would cause major issues. I would instead use a LabJack UE9 or T7 which is Ethernet based, or some other Ethernet based device. Likewise, USB->Serial is cheap and convenient, but it isn't reliable, especially if you just buy a random converter from an unknown vendor, but in many cases it doesn't matter. And often you can script around it, such as in your case. But you are going to get weird things happen like what you are seeing. Note: Over the years we have found that the serial converters from SeaLevel tend to be much more reliable than the generic ones from the generic web, so if you have to use a USB to serial converter, buy one from them.
-
You could use an export set, or if you want real control over the file format, use the low level file functions. For example: private handle = file.open("c:\data\myfile.txt",0,1,1,1) file.write(handle, "Here is some data:" + myChannel[0]) file.close(handle) The Logging part of the user's guide has the description of all the file. functions. Those 0's and 1's in open correspond to: Read, Write, Append, Text, so what I have in the example is not to read, but to write; to append and not overwrite data, and that I'm writing a text file (which means it generates a new line with every call to write())
-
Hi, I would like to write data into a txt file every time a given event occurs, which I would like to investigate later. So I want new data to be written into the same txt file, into a new row without overwriting previous data. How can I do that? Thank you in advance!
-
Thanks for the suggestion. I'm actually seeing this several different serial ports: * With my USB-RS485 converter, it's 100% reproducible * Using NPort virtual com port drivers, the issue occurs roughly 1 in 3 times I click-through the configuration screen * still TBD: whether or not this issue occurs in relation to a physical RS232 port What I don't understand is why the initialization routine would de-initialize a port (what it seems is happening in this situation).
-
Opening the configuration screen and clicking save reinitializes the port, which apparently is what your port requires. I've seen this occasionally with USB->Serial converters. You can achieve the same thing in script by simply doing: device.myDevice.initComm() and with that you can easily right a little script that reinitializes the port whenever it doesn't see any data for some time period, say, a few seconds.
-
I've been using version 18.1 and see strange behavior related to serial ports. Immediately after creating a new serial port with the correct port parameters, I see no traffic on that port. However, once I open the port configuration screen and press Save to close, traffic immediately appears. Nothing actually needs to be modified on the configuration screen, it just needs to be opened and closed. This behavior was observed when setting up three different serial devices, and it's reproducible for me too: 1. Open Comm Monitor for port in question (COM7 in this case, assume there is already traffic flowing) 2. Right-click and choose Configure... 3. Do nothing and press Save to close the window 4. Observe traffic has stopped 5. Right-click and choose Configure... 6. Do nothing and press Save to close the window 7. Observe traffic flowing again 8. Repeat again and again I saved a copy of the control document in both states: * with traffic flowing: `compostpile-msmts.ctl` * with traffic stalled: `compostpile-msmts(stalled).ctl` Here is my full environment: * DAQFactory 18.1, Base Release, build 2347 * Windows 10 Enterprise running as administrative user * COM 1-6 are physical ports not in use * COM7 is an Airmar brand RS485-usb serial adapter * port settings: 4800/8n1, 1000ms timeout, no flow control * sends several NMEA0183 compliant streams * other 2 COM ports are virtual comport drivers linked to an nport 5610-8-DT serial port server compostpile-msmts.ctl compostpile-msmts(stalled).ctl
-
Thanks I managed to get it working with system.remotefull.GetHistory("HV_Power_Active", 0, 3600) remotefull being a full stream connection as it wont work with the lite stream. Also when i set the 3000 to 10,000 it downloads clearly from the persistence data and displays on remote version for a second or 2 then goes back to just 3600. (When i did this server HV_Power_Active history was set at 3600) So 3600 data points is good alot better than none. I guess if there is a way for me to save the data to persistence on the remote that would be good. I also change the history length for HV_Power_Active on the server to 10,000 so i can load up 10,000 points on the remote copy and it stays.
-
You need to provide the channel name in quotes. Otherwise the function looks for the value of the symbol HV_Power_Active locally. So it should be: remotelite.GetHistory("HV_Power_Active", 0, 3000) Note that GetHistory will clear the history on the machine that calls the function. The new data coming in overwrites any data already accumulated.
-
PlotData will become an array of CData objects over time, so you'll have to create multiple traces. But to start, if you only have the code above, it would be: component.Graph2D.test1.strYExpression = "plotData[0].ydata" component.Graph2D.test1.strXExpression = "plotData[0].xdata" Once you have more data sets, you'll have to create more traces, then index into plotData to access the different data sets.
-
I'm not completely sure it is causing the crash, but you have a while(1) loop with no delay in it, so that sequence, when run, is going to run as fast as the CPU will allow and use all the CPU power of one of your cores. I would add at least a delay(0.1) before the endwhile and see if that helps. If it does not, then you should consider upgrading to the latest release.
-
I AM USING AZEOTECH SCADA V16.3. I AM CONNECTING 4 NOS OF PLCS. WHILE I AM NOT CONNECTED WITH ANYONE PLC THE SCADA SOFTWARE IS HANGGING TOO MUCH. SO THAT I HAVE WRITTEN THE BELOW SCRIPT. while(1) if (device.PLC1.Connected) device.plc1.ClearBypass() else device.plc1.SetBypass() endif if (device.plc2.Connected) device.plc2.ClearBypass() else device.plc2.SetBypass() endif if (device.plc3.Connected) device.plc3.ClearBypass() else device.plc3.SetBypass() endif if (device.plc4.Connected) device.plc4.ClearBypass() else device.plc4.SetBypass() endif endwhile THE ABOVE SCRIPT IS ON AUTO START MODE. ISSUE IS WHEN I AM DISCONNECTING THE NO.1 PLC(PLC1) THE SCADA APP CRASHES AFTER 20-30SECONDS. AND THE ERROR CODE IS AS BELOW. RESOLUTION NEDDED IS:- IF I WANT TO CONNECT 4 PLCS THEN WHAT IS THE CODE I HAVE TO PUT.(WHICH WILL NOT CAUSE SCADA HANGGING ISSUE OR APP CRASH.)
-
You have to give both the Graph itself and the trace a name. The graph is named just like any other component. The trace name is set on the Trace properties page, or if programatically adding traces. Then it is simply: component.myGraph.myTrace.Color = RGB(255,0,0) for example. This would set the trace to red.
-
I am wanting to change the color of a trace with script what is the syntax to use?
-
That would have to be done on the device. The method would vary depending on the device. More modern Ethernet devices often have a web server so you can just browse to the device. Serial based devices often either have DIP switches, or alternatively, use a specific Modbus register to change the slave ID, however, that register # is not universal, so you'd have to read the device's documentation to determine this.
-
Hello everyone, At the moment i am working on a modbus project. I am trying to change my slave ID but so far without any luck. The program i use is Modbus poll but i can't seem to figure out how to change the ID. Does anyone have any suggestions on how to change the slave ID? The ID needs to change from 01 to 30 (1E) Thanks
-
Hessel joined the community
-
Can you help with the syntax to add traces with the data from plotData variable? I am not understanding how to get this. Here is my sequence class CData local xData local yData endclass private newData = new(CData) newData.xData = AIN2 newData.yData = AIN1 PlotData.append(newData) AIN2.ClearHistory() AIN1.ClearHistory() component.Graph2D.AddTrace ("test1") component.Graph2D.test1.strYExpression = ???? component.Graph2D.test1.strXExpression = ????
-
Channel Numbering
AzeoTech replied to boliva's topic in Channels, Conversions and general data acquisition
Yes, this is expected. It has to do with how Modbus addressing works and is a side effect of a poor choice they made when they first created Modbus. At that time they for some reason thought that electricians, who were the primary people installing PLCs at the time (like 40+ years ago), could not count from 0 like programmers do. Silly really as all the electricians I know are quite smart. So, even though Modbus internally numbers everything from 0, they started addresses at 1. On top of that, they put a digit in the 10,000's place to indicate the type of register. So 40,001 is the first Holding register, and 30,001 is the first Input Register. 10,000 is input status and 0 is coils. I don't know why they skipped the 20,000 range. Anyhow, when you ask for 40,001, what actually is put in the Modbus query is 0. And when you ask for 40,184, what actually gets asked for is 183. This was all fine for a while, but then PLC's got fancy enough that they needed more than the 9,999 register limit of this notation. Modbus itself allows for 65336 registers in the protocol, but the notation was limiting it to 9999. So, manufacturers started simply documenting registers the way it is in the Modbus packet instead of this arbitrary notation. So, 0 is 0, 1 is 1, and 65535 is 65535. Nowadays the problem is that some device manufactures document their hardware using the 40,001 notation, and others use the 0 indexed notation. And yet others just do it completely wrong, using 40,001 notation but actually keeping 40,001 in the packet, or using 0 indexed, but subtracting 1. Those are rarer fortunately. DAQFactory tries to figure this out for you, but doesn't always do the best job. Basically, until you read a register in the 30,000-50,000 range, it will assume that the channel # you ask is exactly how it should go out to the device. So, 1 is 1, 5, is 5, 0 is 0. Once you read something in the 30,000-50,000 range, it assumes you are going to stick with that notation, so 40,001 becomes 0; 40,002 becomes 1, etc. It just strips the 10,000's place and subtracts 1. The type of register is determined by the I/O type. Now the problem is if you go back and ask for Channel #1, it is still doing this, so 1 becomes 0 now instead of 1. This is why it didn't work until you read 40,001, and then did work after that. The register is actually at 0, but you tried to read 1, which is invalid for a float that requires 2 registers and starts at 0. Once you read 40,001, DAQFactory requested register 0, the correct register, even when you subsequently requested 1. The bottom line is that you have to choose which notation you want to use. It is totally a documentation thing and has nothing to do with the actual protocol and communications or the device, as that is always using 0 indexed register numbers. I personally do everything in 0 indexed notation and just translate in my head. So when I see 40,001 I just tell DAQFactory to read register 0. And when I see 43,483 I put in 3482. I don't really ever put use the 40,001 notation, even when the device's docs are provided using those numbers. -
I started a new project, completely blank, using a new Modbus capture device. My channel's I/O Type is Read Holding Float R Words. If I select the channel to be 1, I don't get accurate data in the "Watch" window. If I have my channel set to 0, I get what I would expect. If I now change my channel to 40001, the data streams as what I would expect and if I change my channel back to 1, it remains accurate. Is this by design?
-
I have a chart with expression HV_Power_Active [0, 3000] on the runtime copy
