• Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About MrDeathStar

  • Rank

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

1,741 profile views
  1. I will need to determine if the company will allow us to share the .ctl document as the experiments are under IP. However, I can comment on the behavior. Yes, the memory usage of DF was higher than other applications we have created...approximately 1.2GB at the time of the event. All charting and channel histories were full and working as expected. I am sure that could contribute to an issue, but the application has been in use for several months without issue and was recently restarted last week (before the problem was observed.) While all pages in the application were slower, the typically slower pages having graphs were not impacted as much (maybe only twice as slow). Pages containing button, text, variable value and symbol components were far slower. (I only guessed symbol components could be the issue because two pages not having them were far faster.) The 60ms main page, for example, went to 780ms by itself. It contained a handful of buttons, panels, and symbol components. The application does use a few canvas components too, but not on all pages. The pages with canvas components have several symbol components as well, so it is hard to separate. The slowest page is usually about 250-350ms, but was operating near 3000ms. The application is using LabJack and makes calls to the LabJack library directly. The main threads for collection and logging were reporting correct delays, etc. The command / alert console window (as always) was in use heavily, but newly created pages were fast. So it could be that accessed something was slower, but the main page does very little. It is true that several screen components do make calls into a common script object to collect state (very quickly conditionally accessing different local variable members), so it is also possible that if that object was somehow 'locked' too long in script it could delay rendering. That common object only handles GUI state and has a fast background thread to monitor state from other application objects. Is uses a 1-2 second delay between attempts. The application is written using several processing threads managing their own event 'queues' to avoid contention. The thread processing seemed to be operating correctly during the slowdown...only screen updates and general slowness in the GUI were observed. It appears this may be an unusual condition so we will continue to monitor it and report again if it occurs. I submitted another strange edit box problem observed once and wonder if it could be related, as it too is a GUI control element. I welcome any further comments you may share.
  2. One of our applications that typically runs continuously for many weeks/days suddenly became extremely slow (over this past weekend). The operator experienced page refresh rates of 1800 to 3200ms on pages usually running 70 to 300ms. Application threads seemed to be running at expected rates with typical 'delay' intervals. Logging and data acquisition did not appear to be affected, just screen repaint performance. Channel data history lengths had reached their limits many days earlier. DF was the only application running. The application is built as a sequence of tabbed "pages" where a tab's page is shown by merging it with the main control page. Each page can be separately displayed (without being merged) through the DF interface. Surprisingly, some pages containing several graphs were found to be fast, while other page seemed to be abnormally slow. The common element on those pages seemed to be the Symbol components. However, creating a new page and adding a symbol did not seem to be a problem. The pages with symbol components are typically just small icons and such for custom looking buttons, and the graphic shown may depend upon some variable value. This is the first time we have experienced this issue with DF (though we have been previously using 15.9x versions). Have there been any reports concerning symbol components (i.e. or internal DC memory handle leaks, etc.) that might explain the sudden speed decrease? The only solution was to restart the application, which required an experiment interruption, but all started working again as expected. Thank you for your time. DF: 16.3
  3. MrDeathStar

    Dual USB keys

    Can DAQFactory identify two USB keys? We are using USB keys for our runtime licenses and developer licenses. The runtime license is typically plugged into a computer locked in the equipment cabinet. An external USB connector provides cabled access to this PC. When I insert the developer USB key, I was hoping it would override the 'runtime' license and allow me to make local code modifications. Alas, DAQFactory reports that the license it finds is only runtime...I need to remove the internal USB key before it will detect the developer license. If we had installed the runtime directly (without using a USB key) would this have operated as expected? Your comments/thoughts are appreciated...thank you.
  4. MrDeathStar

    Reserved Word Warning

    Today I was moving code from some old sequences into a single new sequence with a switch statement. The old sequences were being called by some variable value components and worked well. I updated the components to call my new sequence and DAQFactory locked up. Sequences that demonstrate this problem are attached. TimeAsVarName.ctl It is interesting that the old code works well but a lockup occurs if I use the case statement (with the variable declared outside the switch code). The problem seems to stems from the use of 'time' as a variable name (since 'time' is likely a reserved word). It might be a nice future feature to have the parser fail with a warning if a reserved word is declared. Not sure why DF hangs.
  5. MrDeathStar

    Gettextextent And Font Size

    I figured it might have been a simple SelectObject related thing. The dummy TextOut was a stab in the dark, but if it had worked I would have probably questioned potential DC object leaks from not selecting it out. Since the forum did not have much regarding GetTextExtent, I gather it is a seldom used/tested feature. So, thanks again for a speedy fix with the 2230 update!
  6. I am using the Canvas component to center some text features among custom graphics. I call Draw.SetFont() and Draw.GetTextExtent() to calculate text positions before drawing. However, GetTextExtent() seems to report the same pixel size regardless of the font size chosen. Since SetFont() does not use a DC argument, I tried a dummy TextOut() using the chosen font to see if that would set the DC before calling GetTextExtent. It did not work either, so any help is appreciated. Thanks. (ver. 2203/2224/2229)
  7. MrDeathStar

    Text Component In Popup

    Did not find 2225, but it works as expected now in 2224. Thanks!
  8. MrDeathStar

    Flatten() Function Trouble

    It works...thanks (and I am not intending to use it with time data, so all is good).
  9. I was working with some point arrays (for drawing functions) and came across this puzzle with Flatten. It seems that I get different results depending upon how the source array has been previously manipulated (e.g. applying constants vs variables). The code is very short and outputs to the console window. It is particularly visible if the offsets chosen are negative. Could I be making some error with array allocation, etc.? v5.91 / 2203 TestFlatten.ctl
  10. MrDeathStar

    Text Component In Popup

    FYI: Also affects variable value fields too...transparent background is forced white in the popup (bummer). (beta 2210 through 2222).
  11. Wow...thank you very much, I'll give 2222 a try over the weekend as we can really use it! (FYI: if no parameters are given (stupid me) to LJM_Close() it reports "improper number of parameters in eReadName: Line 1"...not 'in LJM_Close'.) And hey, thanks for all the time spent in forums responding to various issues and 'features' I bump into during development. I always appreciate your kind comments, workarounds, solutions, and explanations. To me, a key strength of DAQFactory is scripting, and that is the reason we chose your package for our needs. But, I do feel like a pest sometimes reporting rough edges I find here and there in the forum...maybe there is another 'bugzilla' like place for that? In any case, much appreciation extended to you and your developers. Regarding 'beta features', I know you probably can't comment on future releases, but I was just curious if there is a basic release plan/interval with DAQFactory. We have only been a customer since April. The latest release 5.87c was last December, and 5.91/2203 last October was only RC. But we have needed beta 2215 for graph reasons (and now probably 2222 for this LabJack T7 issue.) It's not really an issue since beta is working well for us, but as product features can change, it's nice to be aligned with official releases.
  12. Yes, I too think it's great how DAQFactory acts as a pass through for most devices because it does allow companies to improve their drivers independently. "It gets a handle when it opens the device and then continues to use that handle." - This was my finding, and yet it would be appreciated if that handle could be reinitialized or closed (i.e. some scriptable way to ask DF to close a device identifier/handle or open it again). Currently when a device identifier (i.e. IP address) is set in Channels, DF will open the 'new' device. But returning to a previously used identifier just recycles the old handle which may have been closed. (Even LabJack drivers can close all handles via someones call to CloseAll, so it would be nice to have a recovery procedure for such situations.) Maybe Restart() with a parameter having the device identifier that needs recycling, or some other flag to indicate to DF that its handle is invalid and will require re-open when next used. For now I can reopen a device with the same identifier using my own extern methods into the LabJack driver...but I lose DF T7 streaming capability since those methods rely on the invalid original handle.
  13. We are using ethernet cabled LabJack T7 devices (channels and streaming) and found that the device identifier (IP address in my case) seems to associate with some internal handle used to initially open the device with that identifier. If there is a short network error (or remote T7 power failure) and reconnection fails, LabJack reports LJME_RECONNECT_FAILED. However, at this point DF can no longer reconnect to the device. I cannot find a way to reopen the device using the same IP identifier, since it remains associated with the now non-working handle. I must close/reopen my .ctl file. If I setup my own extern methods to call into the LabJackM library, I can use 'LJM_Open' to obtain a new handle and even call other helpful methods such as 'LJM_eReadAddresses' as needed. If I receive a connection error, I can close / reopen the device and obtain a new handle. However, streaming methods in the library seems to require special support which I may not be able to create myself with this extern method (and DAQFactory already has nice methods for this, as in the LJM_Stream example). Is there some way to reset any DAQFactory mapping between 'identifier' and its internal LJM_Open handle? Or, is there some way to force close/reopen of the device again? I tried Channel.Reset(), and creating a new Channel, but it did not work (and certainly not for LJM_eWriteName methods). Once such a device error occurs, DAQFactory seems to attempt using the same handle for the given identifier. You can duplicate the problem by setting up an extern method to manually call LJM_Close on DF's handle (or LJM_CloseAll). While not totally fair to DF, it does show that once the driver handle goes bad, DF cannot reconnect to the device using the same device identifier (e.g. IP address). Since it's possible that a wireless T7 may experience such troubles, it would be important to have a reconnection after failure procedure that does not require rebooting the DF application. Thanks for your comments.
  14. Not sure where to report this issue as I am using 5.91 build 2215. Text Components with transparent background display correctly on a page, but have white backgrounds in a Popup. They worked as expected in 5.87c and 5.91 build 2203, but seem to have lost this ability since build 2210 or earlier. (It does seem that Popups in the unreleased builds don't flash a white background before painting the page color...nice fix). Have the changes since 2203 limited some functionality in popups, or could this be just a simply side-effect of another change? Thanks for your insight. PopupWithTransparentText.ctl
  15. Thanks for your detailed reply and design tips. Regarding (1), I do have a menu but it's in the main page. I can change the menu to its own page and always have it last so the button only changes pages above. In this instance the menu was on the main page and I was trying to have one of the 'menu' buttons toggle a 'help' panel over part of that page. I did not put any components in the 'help' panel (including a close button) since, as you mention, clicks might pass through to the page below. I could use a 'hidden' panel and have the menu button make it visible/hidden. Of course, I could also use an actual popup window too. Thanks for your tips. Regarding (2), thanks for the double-click are correct.