Kristoff

Administrators
  • Content Count

    265
  • Joined

  • Last visited

  • Days Won

    12

Everything posted by Kristoff

  1. Hey, As you mentioned the analog input range of OpenLogger is +/-10V and the ADC is 16-bits and your math is correct that theoretically that would result in ~0.3mV as the smallest voltage difference we can measure. In reality every non-ideal system component starts to chip away at that precision. For OpenLogger our tests show that we can consistently measure to about 3mV (effectively 12 bits of resolution for our ±10V range) and assuming the OpenLogger is appropriately calibrated our accuracy is typically within about 10mV due to noise and distortion. We can improve these values by oversampling and averaging to get within about 1.5mV which results in an effective number of bits (ENOB) of about 14. The Digilent Instrumentation protocol was originally designed to support OpenScope MZ and returned values in units of 1mV. We decided to use the same units in our communication with OpenLogger to leverage some of the existing commands. What you are seeing is not an error with the export, but a side effect of our decision to return values from the hardware in 1mV increments since anything beyond that resolution is noise. Let us know if you have any questions about this. Thanks! -Kristoff
  2. Adding this to the FAQ here under When will all of the v1.0 features be available? We'll add more details and updates there.
  3. Hey Bevets, We plan to evaluate better Linux and Mac support after we get the main feature set complete in the OpenLogger firmware and WaveForms Live. Our goal is to have Wifi released by the end of March. Once we support Wifi, Mac and Linux will be a viable option via wifi, but you'll still need a Windows machine to connect via USB and update the device firmware. We're working on logging to the SD card now and should have a release ready in the next couple weeks. The first release will probably not include logging on boot, but that should be released shortly after logging to SD. Let us know if you have any more questions or suggestions. Thanks! -Kristoff
  4. Hey MRE, Sorry to hear that you got off to a rocky start with OpenLogger. I'll add some links here so others can benefit from your feedback. All of our OpenLogger documentation is linked from the OpenLogger resource center and I suggest all new users follow the instructions in the OpenLogger Getting Started Guide for initial setup. You can find the pinout diagram on the OpenLogger resource center as well (top left side). The pinout diagram is also available once you're connected to the device in WaveForms Live (see image below). I wish we could have labeled the pins on the PCB, but unfortunately there was not enough room. I'll add a work item to update the error message to explicitly mention that you need to install the Digilent Agent rather than just "... Please make sure the Digilent Agent is running". For future reference you can download the Digilent Agent here. Unfortunately none of the issues in the thread you referenced were as simple as the Agent not being installed. We do the best we can to test on a wide variety of hardware and operating system permutations. Since we can never catch all the corner cases we try to be very responsive and help troubleshoot any issues our customers run into and build the fixes into the product so everyone can benefit. This is one of our first releases where we're using a new file manager to host our downloads. We're working on making it so won't be prompted to register more than once, sorry for the inconvenience while we work this out.
  5. Wifi support will be added in one of the next updates. I expect it should be released by mid March. -Kristoff
  6. Hey, The getActiveDevice has not been implemented. I added a note to the documentation to call that out. During initial development we started by defining the specification and then found some commands were not required for OpenScope/OpenLogger to function with WaveForms Live. Logging to RAM is a bit different than logging to a file on a non-volatile storage device (SD in the case of OpenScope / OpenLogger). When logging to RAM it doesn't actually create 'files' in RAM, it just logs to a buffer and the buffer will be overwritten when you stop logging and start a new log. Let us know if you have any more questions about any of this. Tha -Kristoff
  7. Hey Adithya, Any commands sent to the agent's root endpoint http://localhost:42135 will be passed through to the active device (if there is an active device). Since there is no active device in your case you get the error you noted. You can send commands to configure the agent to the 'config' endpoint http://localhost:42135/config The Agent code that handles these commands is here for your reference. Let us know if that works for you or if you have any more questions. Thanks! -Kristoff
  8. Hey arnz, lo is the loopback adapter. It's a virtual network adapter that just 'loops back' any network traffic sent to it. You can ignore it for what you're doing. It sounds like when you use LabVIEW to configure the network adapter it somehow saved the old (DHCP) IP as the static IP. I don't have the software in front of me, but off the top of my head I can't think of a good explination of how this would happen. Can you post a screenshot of the selection(s) you made in the network config menu? It's good practice to not manually assign IP addresses that are in the range that the DHCP server is leasing out, but it shouldn't cause a DHCP server to crash. If it did it may be an indication that the DHCP server is misconfigured. -Kristoff
  9. That's right. The trigger pins are hardware capable but the current version of the firmware has not yet implemented support for them. -Kristoff
  10. Hey Marty, Thanks for the feedback. I created an issue for this on GitHub. For now I recommend you just make the change locally to get the correct data to pass through. -Kristoff
  11. Hey Marty, The Max32 + Ethernet Shield is a supported combination with LINX. You can see all the LINX supported devices here. Let us know if you have any questions about this. Thanks! -Kristoff
  12. Can you provide more details on what hardware and software you're using, what exactly you would like to accomplish and what parts you're having trouble with? The more details you provide the easier it will be for us to help you. Thanks! -Kristoff
  13. Fair enough :D. Glad to hear LabVIEW + WF32 is working well for you. I had a lot of fun creating that and still have my original demo with a WF32 with WS2812 light strip controlled by LabVIEW mounted on my porch ceiling. -Kristoff
  14. Hey, LabVIEW support doesn't depend on Jessie, but it was developed and tested on Jessie and has not been updated for Stretch. The LabVIEW runtime should still work just fine, but there may be changes in the newer OS that require some manual setup / modification. For example SSH is not enabled by default anymore, so you'll have to enable that before following the standard setup procedure. RPI has been pretty good about not breaking backward compatibility for the I/O, but I haven't tested it so I can't say for sure that all the I/O will work without modification. -Kristoff
  15. Hey Marty, 1. I would go with RPI 3. It's better hardware and LabVIEW should work fine (just make sure to get the right...old...version of Raspbian and it will be easy). 2. I would expect everything to work on the 3+. There may be some extra steps required to get things setup, but I'm not aware of any reason it wouldn't work. That being said I haven't tried it. 3. The LINX add on for LabVIEW includes the LabVIEW Runtime for BBB / RPI which is what enables LabVIEW code to run on the target. This runtime is licensed for non-commercial use only. It will work with a commercial license of LabVIEW and you can still use it for hobby / educational use, but you would be violating the license agreement if you deploy LabVIEW code to BBB / RPI for commercial use. The runtime is also only available for LabVIEW 2014. Let us know if you have any more questions about this Thanks! -Kristoff
  16. James hinted at this but just to be clear there are two areas where you can find reference material for Digital Discovery. The Digital Discover reference center focuses on the Digital Discovery hardware and links to the Digital Discovery hardware reference manual. Since the WaveForms software works with many Digilent products it is documented separate from the hardware in the WaveForms reference center and it links to the WaveForms reference manual.
  17. I resolved the issue and updated the repository on GitHub. Converting the CSV in WaveForms Live and dlog-utils should both work now. Let us know if you have any other questions and thanks for the feedback! -Kristoff
  18. Hey, I converted your DLOG in WaveForms Live and it looks correct: You can retrieve and convert small log files directly in WaveForms Live by clicking the folder icon to browse files on the SD card. I did the same with the DLOG Utilities and had the same issue you did. I'll have a look and see if I can fix the util. -Kristoff
  19. If one case of an event structure is executing while another event (or many events) occur those events will queue up and be handled int he order they occurred, so the behavior your describing sounds more like a symptom of the problem (ie the wait till complete VI not waiting) rather than something caused by the event structure. I would return to this experiment and try to determine the first VI to behave not as expected. Can you post the code for this one? Are you doing closing the stepper and the Arduino at the end? If the Arduino is not reset it's possible memory is leaked in the firmware when allocating / deallocating steppers.
  20. I once bought a 10 pack of USB micro cables because they were cheap, thinking that with 10 cables I'd always be able to find one. They got disbursed throughout my collection of cables before I realized they were 'charge only' cables. They haunt me to this day... Let us know if you run into any more issues and we can help suggest troubleshooting steps. Thanks! -Kristoff
  21. Can you post the Logger>>Read response packet as well as the converted CSV? Thanks! -Kristoff
  22. There is a potential for issues when using 'Stepper Wait Till Steps Complete' with multiple steppers. It looks like the firmware sums the distance remaining for all steppers and then the LabVIEW side checks if it's not equal to 0. If one stepper has positive x steps to go and another stepper has negative x steps to go the VI would report that there are no steps remaining and the VI would unblock. If you're only using a single stepper that shouldn't be a problem, but it is something to be aware of. case 0x33: // Stepper steps to go retVal = 0; for(int i=0; i<8; i++){ retVal += steppers[i].distanceToGo(); } Serial.write( (retVal & 0xFF) ); Serial.write( (retVal >> 8) ); -Kristoff
  23. Firmware source code is here. The code you posted looks like the your first test case. Can you post the second test case? Also, when you say 'Running Continuously' do you mean using the 'Run Continuously button' (as show in the image below) or are you running continuously by placing your code in a while loop? Thanks! -Kristoff
  24. Yes, that is normal behavior. Since you told it to run forever with "maxSampleCount": -1 the "stopReason": "FORCED", indicates that you manually 'forced' it to stop with a command. Let us know if you have more questions about this. Thanks! -Kristoff