• Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About RodSwan

  • Rank

Profile Information

  • Location
    Oxford England
  1. I now have versions 5.91, 16.1, and 16.3 installed and working... mostly ok. I had to unlock versions 16.1 and 16.3 again as I had to do a full re-install to get both working. Problem now is when I try to use the symbol library, it tells me I'm still in demo mode and only allows use of first symbol... but I don't get the "Product Evaluation" dialog when starting DAQFactory. Will this affect running in Runtime only mode as well? Rod.
  2. Thanks for quick reply. Problem with that ithough is that it can get terribly confusing.... running either version and selecting menu "About" both show only version number of latest version (actually that of Daqfactory.exe program) ok..its manageable but rather confusing.
  3. Having an installed base of various versions of DaqFactory I need to keep multiple versions live on my development system. I Just installed version 16.3 into a new directory: c:\program files(x86)\daqfactory16.3 and it removed most of the files from my previous installation in c:\program files(x86)\daqfactory16.1 Thats a pain. I now have to re-install the previous version (hope it doesn't remove the later version!) Rod.
  4. Third new topic as I'm unable to comment on previous topics until they are approved.... Following on from previous topic where page.dialog.backcolor=RGB(x,y,z) doesn;t work on active dialog: Although I can put a panel on the dialog and change its colour, that is not good as, by default, I cannot cover the entire background of the dialog because the size of the dialog is always set to be slightly larger than the largest component. Of course, I can fix the size of the dialog but that is a pain. Rod.
  5. Hi, Pre version DF5.91 I used "page.dlg.backcolor" to show user if entered data is acceptable (green=good, red=nogood). This has stopped working in DF5.91. I can set colour before calling page.dlg.popupmodal() and it works, but once dlg is displayed I can't change it until it is closed and popped up again. Same applies to Modeless popups as well. How can I recreate this feature in 5.91? Rod
  6. RodSwan

    Tcp - Confirmation Of Output Channel Changes

    Reply and CTL file sent in private email...
  7. RodSwan

    Tcp - Confirmation Of Output Channel Changes

    Hi,Yes, reads continue without problem. I have modified code in "AppEverySecond" sequence (executed 1 every second) to test it more often: global OP2Test=0 function AppEverySecond() .... while(1) ..... if (OP2 == OP2Test) OP2Test=!OP2Test //flip flag Op2Count = 0 endif if (OP2 != OP2Test) Op2Count++ try // setting it. OP2 = OP2Test catch() logmsg("Caught setting OP2" + strLastError) endcatch if (OP2 != OP2Test) logmsg("setting OP2 to " + OP2Test + ", failed... count " + Op2Count) endif endif .... wait(1) EndWhile Difficult to follow in the comms log as I'm only able to grab (i.e. copy to clipboard) about 10 seconds worth from the Comms monitor - Is there anyway to send this directly to a file... or even just be able to grab a couple of minutes worth?... to follow a complete set OP2 to completion needs at least 95 seconds on the one I've just tried to log. So, I've checked the Comms log and it seems that DF waits an (as yet) indeterminate time before sending the command to the Modbus device. I have two files attached (the DF Comm log and my own logfile) that show this. I have not yet been able to identify why it doesn't send the command immediately or what finally triggers DF to send it. I have one example (my log file... too long to get DF Comm log) where it took 209 attempts (i.e. 3 minutes and 29 seconds) to send it and the problem that finally brought it to my attention was an event a week or two ago where it took more than 10 minutes. The comms log trace that eventually gets communicated is: OP2 is Channel 19 (address 018) Tx (16:32:01.299): \000\000\000\000\000\006\001\005\000\018\000\000 Setting OP2 0.... finally succeeds after 95 failed attempts Rx (16:32:01.299): \000\000\000\000\000\006\001\005\000\018\000\000 Tx (16:32:02.038): \000\000\000\000\000\006\001\004\000\014\000\002 The comms all look good - except that the send of the command is delayed. The CPU usage during all of this was around the 10% mark (uVNC remote connection). The priority of the "AppEverySecond" sequence is 5 - Aquisition, though there is no doubt that is executing to completion (well, round the While()...EndWhile loop) as you see from the other logs. HELP! (please!!) Rod. My Log - Showing Setting of OP2.txt Log of DF - Mod1 comms - Showing Setting of OP2.txt
  8. I have a number of independent systems, each talking over a dedicated Ethernet link to an Adam 6050 (multi digital I/O device). I get no errors reported in DF (I have output set encapsulated in try/catch) yet output does not always get set to correct state. once every second code (OP0 is i/o channel and X is desired output state):- if (OP0 != X) try OP0 = X catch() logmsg("Error Caught setting OP0" + strLastError) endcatch if (OP0 != X) CommsErrorCount++ LogMsg("Error Setting OP0") endif endif After each set I check output one second later to verify it has changed. If it hasn't I set it again and log error. Sometimes it takes up to 10 minutes of retries once every second to get output to change. Problem is very intermittent. I have thought it was problem with Adam 6050 but sometimes when problem is repeatedly occurring on a system simply restarting DF clears the problem. Communication to Adam I/O unit is over a very short (about 6 inches) dedicated Ethernet link - only devices on the link are the PC and the Adam unit. Any idea where I should start looking to find source of problem? Is there any convenient way to log the comms (discreetly on the customers live system) so I can confirm what data is sent to and from I/O unit? (as per sods law, I have been unable to recreate problem on test bench ). I think I've had this problems for years, but haven't noticed it before as I only use a single output that changes maybe once per hour or so and when it fails my retry code usually corrects it with in a few seconds. I am currently running DF 5.90 build 2197 on Windows 7 professional SP1. In the channel list Timing and Offset are both set to 0.0. Rod.
  9. RodSwan

    Transferring From Xp To Windows 7

    Hi, Is there any change in the status of this problem? I'v been quite happily running 5.90 (2197) on my windows 7 development system for some time now without problem, and I upgraded 6 runtime machines to windows 7 about 2 weeks ago and they have also been working ok. Today I have replaced all six machines with new PC's, again running Windows 7, and they all now exhibit this problem. I use Registry variable extensively so don't really want to change the code. I've had to temporarily set DF to run in compatibility mode. Does 5.91 help with this problem? Rod.
  10. hmmmm. Yes I understand its as I thought. I think my solution to use a flag to tell the higher priority sequence to do the clear would probably work (and is a lot easier than your dummy serial device) .... Low priority Sequence: ClearCounter=1 High Priority Sequence: If ClearCounter==1 Counter=0 ClearCount=0 else Counter += delta endif but I like your second choice better :-) Thank you. Rod.
  11. I have two sequences that I think have just exhibited an undesirable interaction. Sequence A, thread priority 5 triggered once per second with a BeginSeq() in a channel event. This sequence increments a second channel (Counter) that is defined as a device type "Test" I/O type D to A.... Counter += delta Sequence B, thread priority 2 is triggered perhaps once per hour with a BeginSeq() in an event on a third channel (and sometimes by the UI) which resets the counter... Counter = 0 In 5 years of using Daqfactory this has worked without error. Today I find an instance yesterday where, whilst all other actions in both sequences worked as expected, the Counter did not get reset. Only explanation I can think of is that after low priority Sequence B had updated Counter to 0, high priority Sequence A had overridden the 0 with the incremented value based on the pre zeroed value. Is that possible? A solution would be for me to set a flag in the low priority sequence to tell the high priority sequence to do the reset to zero but is that really necessary? Rod.
  12. I agree, ";" to concatenate multiple lines would be extremely useful in the command/alert window. so for example things like: for(i=1;i<100;i++); x.addvalue(i);endfor could be done (on the fly, during development/testing). Rod.
  13. Any known problems with Usertime.dll and Daqfactory 5.9? I have been using Usertime.dll for many years without problem but this last weekend's change from BST to GMT failed to update in Daqfactory on the eight systems I've had to restart today. They have all recently been updated to 5.90 and I have verified they all have Usertime.dll in the correct (only) Daqfactory directory. The system time on each system did correctly switch to GMT but Daqfactory only switched after a restart. Rod.
  14. As you can probably guess by the time taken to respond to your last question this has not been my highest priority problem, though still very real. As a direct response to your question... No, I can't create a simple document that demonstrates it. Even in a non simple document I can't predict with an accuracy of better than +/- a couple of months when the problem will occur. However, I'm having to revisit it as I still get problems with UI lock ups. When "lock up" occurs (as reported by operators as system "Freezing") system is still running - sequences ticking over nicely logging data, updating components on screen, but there is no response to users inputs. I'd like to make all my dialogues, but I have the problem mentioned last June - i.e. I need to handle keys as they are pressed and, have the system respond when the <Return> key is pressed. I know as Onchar doesn't work in a popup I can use OnKeyDown, but unfortunately whilst that gives me a code for most keys on the keyboard it does not give anything for the <RETURN> key. So when operator enters data and, naturally, presses <Return> nothing happens. I'd have to tell them to press another button on screen to enter the data. Unfortunately that is not acceptable. I think I can live with not working but I can't see a workaround <Return> not happening. Is there any (easy) way to get <CR> in a popup modal dialog? Rod. p.s. this is mostly on Windows XP. Some systems are running under Windows 7, but with a much reduced program that has very little (if any) user data entry.
  15. RodSwan

    Export Sequences

    Hi Matt, One of the 47 points I have relates to the change for the script dump to file. It's only a minor point but is frustrating... The "Save as type" selection on the Script Dump dialog has a small problem. Around 50% of the time in addition to the *.src it has a second choice that is garbage (current example has "Eic!", second test is ok, 3rd test has "Aic!"). Main problem is that when this happens, even selecting the *.src type no files are shown in the File box. p.s. Any movement on the Stopping a Device query? Rod.