Jump to content

ShaunR

Members
  • Posts

    4,849
  • Joined

  • Days Won

    292

Posts posted by ShaunR

  1. I just read a MBRS140T3 document from osemi.com, MBRS140T3 is a chip of Schottky Power Rectifier. Two leads are in the MBRS140T3 chip. That makes me confused blink.gif

    My understand for a rectifier is something like a diode bridge which convert the AC to DC. It should have 2 AC input and 2 DC output (one is gnd) connectors. I am afraid I misunderstand what is power rectifier, so I google it. The answer from google is "Power rectifiers supply power from an AC source to a DC load". ohmy.gif

    Now the MBRS140T3 chip has only 2 leads. One should be AC input, the other one should be DC output. I guess the only possibility is that it cut the negative voltage half cycle and only use the positive half. Am I correct?? If that is the case. How I should connect the Schottky Power Rectifier to get 100% duty cycle in "positive voltage output" (not 50% positive and 50% negative)? thumbup1.gif

    THanks

    It is a single diode which, by itself, can perform half wave rectification . The terminolgy of "rectifier" and "diode" in single diode AC->DC conversion is purely symantics. You will need 2 of them if you are using a center tapped transformer or 4 (more usual) for non- center tapped.

    Rectifier

  2. Hi.

    We have created a TestStand sequence using mainly labview vi code modules. The test sequence is complete and is running as it should in the sequence editor.

    After I used the Deploument Tool to build an image which could be moved a production PC, something went wrong. The test sequence will still start and it seems to run fine, but the execution is extremely slow!

    It doesn''t matter if I run on the production PC or on my computer (where the sequence was created). I can run the sequence from the development location, and everything is ok, I then close the sequence and load it from the location created by the Deployment Tool and it runs slowly...

    It is not because the tracing speed is set to slow, and it seems to be the vi''s themselves that are executing slowly. Almost as if the "Highlight Execution" is on.

    Any idea what is going on...?

    Best regards

    Stephan.

    Try turning "Trace Execution" off altogether. I know you say that your "Trace Execution" is not set to slow, but this phenomina existed on even the earliest versions when the speed option wasn't available.

  3. I guess you could be right, but it could be more the point of checking that your download is ok (from a transfer point of view rather than security)?

    Anyways, there might be other reasons for allowing text files besides my example, so I was curious to see what others think.

    Zip files have a checksum built in. You get warnings/failures if the file is corrupt and you try to extract. Most text files are MD5 hashes which is more of a test of trust than corruption - to ensure the file downloaded IS ithe file you are expecting..

  4. Is the issue here that you are trying to do a two stage process in 1 go? i.e read from a Solaris drive, process the data and save it to NTFS? The 25MB/s might just be the limitation of the solaris drive (ATA 33 perchance?) and you might not be able to overcome that.

    What about slapping a brand new 1TB NTFS formatted SATAII drive (they are cheap after all) in the windows box alongside the UFS drive. Start a flavour of linux (such as Debian) in a virtual machine or as a live CD. Install this Linux-NTFS in the virtual machine or live CD and just copy everything to the new drive. Throw away the old drive or take it home to build you own solaris system :P

    Then run your software on the data, NTFS to NTFS.

    Probably missing something as per usual :P

  5. Hi!

    During the writing of a simple program to test SCPI commands for my instrument, I stumbled on a puzzle. When I send the *IDN? command and afterwards try to read the response, the string I get is ยด1. If I do it again, response is the same. Only after the third reading do I get the serial number of the instrument. The same thing happens when using MAX test control panel.

    The instrument is HM1508-2 (oscilloscope from Hameg), it is connected over USB. I use VISA Open, Write, Read, Clear and Close functions.

    What could be the problem and how can I make the program get the correct response every time? I can post a picture of block diagram.

    Thank you.

    Is the unit addressable? You may be seeing the units address prepended. The manual will tell you more.

  6. We are in a little bit of discussion in info-LabVIEW concerning someone's idea of wanting shift registers available in stacked sequences. Yes. You read correctly. I don't need to start that discussion here because I already know how >90% already feel about that. rolleyes.gif

    However, a comment stirred up a question in me:

    Define "abstraction layers" as they pertain to Global warming/"climate change" LabVIEW applications.

    Thank you. thumbup1.gif

    Not being aware of the info-labview discussion-heres my two penneth.

    In general terms. An abstraction layer is an interface presented to higher level funtions, that hides the implementation. In terms of Labview, a good example of a HAL (hardware abstraction layer) would be VISA.

    • Like 1
  7. Thinking laterally (or is it vertically). You could create a single global event that each control can decide to register with or not. You can then filter the incoming events and take decisions based on either its type (boolen, numeric cluster etc) or a specific control. What this acheives is that changes to the system are consolodated into 1 vi.

  8. Hi all,

    Google Earth is called via ActiveX - it gets ref. from Automation Open, and eventually displays Google Earths "map" inside LV using IWebBrowser....

    Thanks!

    Yep. That would do it. The key point being "ActiveX".

    You can try to make sure the open ref is only executed once (when the vi is started...ie outside any loops) and hope that the "stall" isn't from the get method.

  9. Some exposition before the question:

    I'm trying to restrict access to a tool using semaphores.

    In my top-level vi, I obtain the reference during my "Initialize" state and release it in my "Stop" state. The reference is untouched in any other state and resides in a shift register. When I pull the reference from the shift register, the "Release Reference" vi generates an error, saying the reference is invalid. I'm only to the point of testing my top-level VI, so no other manipulation occurs.

    When instead I obtain the reference before my state machine loop begins (initializing the shift register), I don't get this error. I might be having a mental block, but it's not clear to me what the difference is between the two styles. What am I missing?

    Check to make sure you have "wired through" the shift register. You will normally see this behaviour if there is a case selector with an unwired tunnel. If there is a case which has no wire connecting the left shift register node to the right node, that case will insert a "NULL" reference.

  10. As already stated in another thread, I'd like to set the priority of the VI from within the application. Since many objects are derived from the same class I use reentrant VIs, but the property node to set priority doesn't agree with Open VI reference "prepare for reentrant run" option.

    Can I simply remove the "propare for reentrant run" option and use property node to set Execution.IsReentrant to get the same results?

    Thanks, Mike

    And to add to the problem, once one instance of the of the VI is running, it is not possible to create another instance of the same VI and set its priority...

    Sigh!

    It can be done (including your additional criteria) by saving the vi as a template (vit). You can then open it in edit mode (requirement for changing execution systems and priorities) modify the parms and then run it like this:

    However. This is probably not very helpful in the long term since the priority property is "Read Only" in the run-time engine so if you deploy it it will fail:frusty:

  11. It's a programming language...of course it has a pizzle! Who knows, maybe in LabVIEW 2011 the pizzle will have its own 'clean up' feature.

    -D

    Does it currently auto-grow or do you have to make it grow manually?:rolleyes:

  12. Why not place each parallel loop in separate subVIs and set the execution priority of the subVI?

    You have to do a bit more than that to force LV to run certain vi's is certain threads. This is where "Threadconfig.vi" comes into its own.

    vi.lib\utility\sysinfo\threadconfig.vi

    It all gets a bit tricky from here on in as you need to manually manage what vi's are going into which execution systems and at what priorities. Most of what you need to know is in this thread (no pun intended...lol)

    Loop Timing & Execution difference

    • Like 1
  13. I think that locking particular forums for newbies isn't the answer for a couple of reasons: the mods will be swamped by "why can't I post in LabVIEW General?" support tickets, and newbies might actually have something appropriate to put into LabVIEW General, and I wouldn't want to stop them from doing that.

    Our current policy is that it's the mods' responsibility to move newbies' posts out of LabVIEW General and into a more appropriate place and let the poster know that it's been moved if required. Maybe our mods have become a little too busy to keep that up recently. Maybe we need a couple more volunteers to move posts? I know that there's still a lot of posts in the LAVA 1.0 Content section that need moving - anyone volutneering?

    Well. A sticky at the top would dramatically reduce the "Why Can't I" PMs. And although they may have something to put in the general area (although haven't seen many newbies that don't post relevent to their problems), it might be a worthwile excersise to lock it for a short period to "Train" them and ease the workload on the mods for moving them.

    Just my 2 cents.:ph34r:

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.