I'm having a little bit of a problem with LabVIEW 6.x concerning the motion control stuff. How do I detect whether a limit switch has been reached? So far I haven't found a way to do that. So what I'm trying to do is detect the minimum and maximum position of the attached device. To do that, I initiate a movement by using "Load Target Position" und "Start Movement" (don't recall the exact name of the latter). Now, if the position reaches a limit, the movement stops. But how do I detect that it stopped because the physical limit has been reached? I tried using the error output, but it just tells me that there is no error, although it displays a message box telling me that the limit in the direction of travel has been reached. It also tells me that this is warning 70026. But that number doesn't appear anywhere else, particularly not in the error code where I expected it to be. So I hope I made clear what I'm trying to accomplish and am grateful for any help on that. Thanks in advance.
For completeness sake:
Your looking into the wrong property, 'enabled' means that the device is equipped with a limit switch and 'listening' to it.
Active means that the limit switch is triggered.
Related
The FRAM (Ferroelectric Random Access Memory) Fujitsu MB85RC256V FRAM MB85RC256V-20171207-5V1 says in page 8 that
• Page Write: If additional 8 bits are continuously sent after the same
command (except stop condition) as Byte Write, a page write is
performed.
This needs no interpretation. But then, on the next page it would say:
• Current Address Read: When the previous write or read operation
finishes successfully up to the stop condition and assumes the last
accessed address is “n”, then the address at “n+1” is read by sending
the following command unless turning the power off.
My question regards interpretation of whether the English in "up to the stop condition" means the same as "except stop condition"?
I guess that not only the English needs to be understood, but also how the device works.
I believe that the two are equal, also inferred from trying to understand how the device seems to work:
Write 8 bits device address with R/W=0=write bit,
then write 16 bits FRAM memory address "n",
then do no stop bit because we could now
send an 8 bits device address with R/W=1=read bit,
then continue to read (first from address "n+1") as many bytes as needed,
until the final stop bit.
This will effectively mean that reading from an address, we need to first set the address register to one lower.
Please correct if my understanding is not 100% correct.
Aside: I have used this FRAM in an earlier project, but via a function called i2c_master_16bit_read_reg in obsoleted library module_i2c_master (which is so hard to understand). The newer lib_i2c does not have that functionality, so I have to do it by extending the XC interface function there. I am using lib_i2c 5.0: XMOS I2C Library (XC is sadly also obsoleted for lib_xcore and C by XMOS, but I still have an older xTIMEcomposer system up and running)
I guess that the next chapters of [ref1], "Random read" and "Sequential read" would show rather explicitly that the stop condition P is indeed only written when "all is done".
In other words, "up to the stop condition" does mean the same as "except stop condition".
I will correct here after I have implemented the code, should my own answer not be correct.
I've been developing our company's credential provider for windows 10 for almost a year now.
Now, I encountered a problem. I don't usually ask questions on forums, blogs, because in most cases I find the solution, but this time I've been struggling with an issue for a month now and I found the root of the problem.
Brief description of the problem itself: The credential provider uses a combobox, which worked before without a problem. Now, I rewrote the whole code to manage a big update, but a strange bug got into the system. The bug only occurs at a specific scenario. I'm developing and testing the code on my personal laptop.
The scenario:
1) The laptop is plugged in to my monitor / power, etc.
2) I make it go sleep.
3) I unplug all cables (including power).
4) I wake it up from sleep.
Than, the combobox doesn't show a default selected item, it's empty. When I drop it down, it shows all the necessary items. Than the credprov crashes and restarts, than everything is fine.
I know, that in similar "strange" scenarios, in most of the cases, a memory leak or something related causes the problem. When I check the event viewer it shows me c0000005, which is access violation. I started to debug where the violation is. Than I found out that the program refers the combobox item list array (actually vector in my case) at a very very high index (out of range could be the reason for the violation). The actual index is obviously stored in the "selectedComboItemIndex" variable (DWORD).
I was curious when did it change to this strange number, than I found an unexpected behavior.
The SetComboBoxSelectedValue method randomly gets called once (when the bug happens) with an insanely high index value. I don't even call this method in my code, so I have no idea, why does it get called. The call happens even when I don't drop down the combobox.
I give it a chance that it could be a bug in the credprov itself. What do you think? Have you seen this problem before?
Thank you in advance!
I solved the problem by stopping to use "SetSelected" and "SetDeselected" methods. Furthermore, I filtered the "SetComboBoxSelectedValue" input parameters to accept valid numbers only. When the index parameter is invalid, I recall the same method with the index parameter replaced to the first item (0).
I'm not sure if this is the good website for ladder logic programming questions but I will it a try.
I'm using a Click PLC C0-01 DR-D by Koyo (Desc page: http://www.automationdirect.com/adc/Overview/Catalog/Software_Products/Programmable_Controller_Software/CLICK_PLC_Programming_Software) with it's free software. I'm trying to make a program in Ladder Logic to executes multiples operations by the PLC. To keep track of the current operation, I use an integer value I'm incrementing as the current operation ID. However, I'm not able to reset this value to 0.
First I tried with the COPY but there's a radio button to ignore zeros. This radio button is checked and disabled (can't change it). . The documentation of the software says "Option: This Option is available when the Source is a Data Memory Register Address and the Destination is a TXT Address." But since I just want an ID and I need to compare this ID with = everywhere in my program and increment it, I don't want to put a string.
Then, I can use math to assign a formula to a variable. I tried put zero and it's working half the time. Note that the "One shot" checkbox isn't selected even if it may to be acting like so.
About this option, the documentation says "One Shot: Select One Shot to solve the formula only once after each OFF-to-ON transition of the enabling rung."
However, to be able to set the value to 0 again, I need to restart the PLC. When I first execute the program everything is fine because the value is already 0. When I restart it, the value didn't reset so it's still 7 and it skips all my operations. Then it resets to 0 (it's doing so at the end) and when I restart the PLC, I'm able to run it normally for one time.
Here an example of the current passing but the value not set:
Is it a bug from the PLC ? Is there a workaround ?
In short, I'm looking for a reliable way to set a value to 0.
Thanks in advance for the answers. Sorry If I violated 40 rules, I'm new and happy to join this community.
I though I resolved my problem but I just pushed it further. Thanks to Garry Shortt with his youtube channel dedicated to PLC programming for helping me out with my problem.
His explanation to the problem is "Changed the math to a copy command and placed it in the main program where you had it before. The program seems to work well.
The only thing that I can think of is when you use subroutines, and they are not being scanned. The items within the routine is the same unless you them changed in another part of your program."
Hope it will be helpful for someone someday.
I'm becoming mad trying to figure out how to resolve this task. My goal is pretty easy, copy a file on the USB stick every time that it is inserted and then release the USB stick turning off the LED. What is the best way to solve it?
1) I found this article
http://geekswithblogs.net/BruceEitman/archive/2008/06/13/windows-ce-monitoring-for-disk-insertion-to-add-support-for.aspx
or
http://geekswithblogs.net/BruceEitman/archive/2008/06/13/windows-ce-monitoring-for-disk-insertion-to-add-support-for.aspx
but I can't translate it on VB.NET project.
2) Then I read that is enough to use RequestDeviceNotifications for block devices. But How can I do that in VB.NET?
I would like to avoid OpenNetCF if possible.
Thank you
Since you don't want to "use OpenNETCF" I assume that you don't want to use any libraries or capabilities not built in to the CF. We'll skip the argument of that silliness and the "value of your time" discussion and take that as a requirement.
What you need to do is:
Use P/Invoke to call CreateMsgQueue. That's going to give you back a Handle. You'll probably want to do CloseMsgQueue as well for completeness
P/Invoke RequestDeviceNotifications and pass it the handle returned from #1 above along with the DEVCLASS GUID value for the device notifications you want - probably STORE_MOUNT_GUID. Again, adding StopDeviceNotifications for completeness is a good idea.
At that point you'll get a message on the queue whenever a insert or remove happens. You then call ReadMsgQueue to get the DEVDETAIL data in the message.
Parse the DEVDETAIL and look at the fAttached member.
It'd take me a while to write that for you, so you'll need to do this on your own.
Start writing the project, find P/Invoke routines for the calls you need (like FindFirstFile and CreateProcess). On SO, have a look at Storage Card Problem In windows mobile and How to register form for WM_DEVICECHANGE message in windows mobile.
You are only going to be dead in the water if you can not find a particular call that you can't make.
As you work through your project, post (or search for) the actual problems you run into.
Otherwise, it sounds like you are asking someone to write the project and hand it to you.
What error checking do you do? What error checking is actually necessary? Do we really need to check if a file has saved successfully? Shouldn't it always work if it's tested and works ok from day one?
I find myself error checking for every little thing, and most of the time if feels overkill. Things like checking to see if a file has been written to a file system successfully, checking to see if a database statement failed.......shouldn't these be things that either work or don't?
How much error checking do you do? Are there elements of error checking that you leave out because you trust that it'll just work?
I'm sure I remember reading somewhere something along the lines of "don't test for things that'll never really happen".....can't remember the source though.
So should everything that could possibly fail be checked for failure? Or should we just trust those simpler operations? For example, if we can open a file, should we check to see if reading each line failed or not? Perhaps it depends on the context within the application or the application itself.
It'd be interesting to hear what others do.
UPDATE: As a quick example. I save an object that represents an image in a gallery. I then save the image to disc. If the saving of the file fails I'll have to image to display even though the object thinks there is an image. I could check for failure of the the image saving to disc and then delete the object, or alternatively wrap the image save in a transaction (unit of work) - but that can get expensive when using a db engine that uses table locking.
Thanks,
James.
if you run out of free space and try to write file and don't check errors your appliation will fall silently or with stupid messages. i hate when i see this in other apps.
I'm not addressing the entire question, just this part:
So should everything that could
possibly fail be checked for failure?
Or should we just trust those simpler
operations?
It seems to me that error checking is most important when the NEXT step matters. If failure to open a file will allow error messages to get permanently lost, then that is a problem. If the application will simply die and give the user an error, then I would consider that a different kind of problem. But silently dying, or silently hanging, is a problem that you should really do your best to code against. So whether something is a "simple operation" or not is irrelevant to me; it depends on what happens next, or what would be the result if it failed.
I generally follow these rules.
Excessively validate user input.
Validate public APIs.
Use Asserts that get compiled out of production code for everything else.
Regarding your example...
I save an object that represents an image in a gallery. I then save the image to disc. If the saving of the file fails I'll have [no] image to display even though the object thinks there is an image. I could check for failure of the the image saving to disc and then delete the object, or alternatively wrap the image save in a transaction (unit of work) - but that can get expensive when using a db engine that uses table locking.
In this case, I would recommend saving the image to disk first before saving the object. That way, if the image can't be saved, you don't have to try to roll back the gallery. In general, dependencies should get written to disk (or put in a database) first.
As for error checking... check for errors that make sense. If fopen() gives you a file ID and you don't get an error, then you don't generally need to check for fclose() on that file ID returning "invalid file ID". If, however, file opening and closing are disjoint tasks, it might be a good idea to check for that error.
This may not be the answer you are looking for, but there is only ever a 'right' answer when looked at in the full context of what you're trying to do.
If you're writing a prototype for internal use and if you get the odd error, it doens't matter, then you're wasting time and company money by adding in the extra checking.
On the other hand, if you're writing production software for air traffic control, then the extra time to handle every conceivable error may be well spent.
I see it as a trade off - extra time spent writing the error code versus the benefits of having handled that error if and when it occurs. Religiously handling every error is not necessary optimal IMO.