I have a simple idea but I guess it's hard to implement it on simulink. I created a TCP/IP server between a BeagleBone and a simulink block using C code. I have a switch connected to the beagle bone as an input and my idea is to have a display on the simulink block showing if the switch is close or open. I couldn't do it because my client(simulink block) is a c code and it will do the job only once as C code ends the function execution after return to get the value of the switch. Do you guys know any simulink transfer mode or fancy C tip to transfer data between the Simulink client block and the display ?
In a simulator I've been working on we used a Sink block with remote IP address and IP port to export the data calculated at real time to an external listener (this could be on the same machine or connected via network) which in our case was a computer doing the graphics rendering, which was then picked up by a C++ code written using Ogre 3D and by another simulink model using a source block.
We also had an interactive chartplotter display (GPS position indication, if you will). We could access the values generated from simulink by calling the following command any time it was needed:
variable = get_param('Simulator/Chartplotter/YDot','RuntimeObject');
You could also call "set_param" to modify a constant value located inside the simulink model.
I don't have experience in beagle but I imagine you could have your C code execute a matlab scrip which would modify a logical constant present in your simulink model to indicate whether the switch is open or not.
Alternatively you could explore the first option but we only used it to get data out of simulink into the C program, not the other way around as you'd wish to do. I haven't got direct access to the receiving C code unfortunately but if you are really stuck I could ask my colleagues to send me the important bits.
Hope this helps.
Related
I have a real-time Clock module and I'm trying to make an RGB Clock out of it. There is a particular line of code that sets the time and date to the real-time clock module. I put this in the setup code but every time I reset the Arduino it runs that line of code again. Is there any way that I can make sure that once this line in of code is run it will never run again even if I reset the Arduino?
It is a broad question which goes beyond programming. The answer to your concrete problem is "Remove that line of code" from setup, it will not run (I am sure you know this). However, you should provide some physical input (buttons + rudimentary menu-like interface) to set the clock on first usage. A second way of setting the time can be a serial port to which you can physically connect. This requires some code to read that serial port in your loop method.
In the release version of you Clock firmware I would leave just reading the time stored in EEPROM (from RTC module or an external chip), not the hard-coded value in setup.
Your RTC might have a bit saying "RTC stopped", which you might use to switch to "normal behavior". It will be set when removing power and the RTC-battery. The RTC will probably read "1-Jan-1970 00:00" then, and won't increment unless set.
However, your demo code to set the RTC is just demo code, not intended to really use as is. (See Victor's response for more details)
I know there is a way to get all available printers in C# using System.Drawing.Printing.PrinterSettings.InstalledPrinters. But how to get the name of the printer which is attached to say, a USB port? Do we need to hard code the name of the printer? Because, if so, we'll have to change the printer name in the code if the application is run on a different system, which might use a different printer.
How do real POS systems do this? How could I generalize the printing functionality of the application? I am using the library ESC-POS-USB-.NET.
The API will be for standard Windows desktop printers.
The main function is graphic printing on cut sheet paper.
Most receipt printers for thermal roll paper used in POS are connected to a serial port or a network and print using the ESC POS command mainly for characters.
There are many ways to use it to send commands directly from the serial port.
However, there is also a way to use a standardized API that abstracts the functions of the POS printer.
The name of the specification is called UnifiedPOS.
The actual mechanism is OPOS, POS for.NET, JavaPOS, Windows.Devices.PointOfService, etc.
Please search based on those keywords.
I am generating a certain signal (digital pulse) in one of my verilog module running on programmable logic in Xilinx Zynq chip. Signal is pretty fast, with clock of about 200MHz.
I also have a simple linux and framebuffer Qt interface running for later controlling my application.
How can I sample my signal in order to make oscilloscope like interface inside my Qt app? I want to be able to provide visual of the pulse I am generating.
What do I need to use to be able to sample enough data at such clock frequency? And how do I pass it with kernel module or mmap to Qt?
You would do best to do what most oscilloscopes do: sample the data to RAM, and only then transfer it to the processor for display/analaysis, at a more "relaxed" pace.
On the FPGA side you will need a state machine that detects some sort of start or trigger condition, probably after a bit in a mode register is set from the software side to arm it.
The state machine will then fill samples into a buffer made of one or more block rams. If you want to placing the trigger somewhere in the middle of the samples captured, you should it as a circular buffer, and have it record continuously, stopping configurable number of samples after the trigger, so that some desired number from before the trigger condition remain un-overwritten by newer ones following it.
Since FPGA block rams are typically dual port, you can simply hook the other port up to your CPU bus for readout. You will probably want a register to read the state of the sampling state machine, and if you go with the circular buffer approach, the address where it stopped, so that you can unwrap the data to a linear record of time.
Trying to do streaming realtime sampling might be possible, but would be a lot harder and it is not clear that you could do anything meaningful with the data so produced in real time. Still, if you want to try you would probably need to put a FIFO buffer in between the sampling and the processor bus, as you will probably only be able to consume data in chunks, while having to service other operations in between, so something is needed to absorb the constant-rate inflow of samples. Another approach could be to try to build a DMA engine which would write samples directly to external system ram, but that will likely be even harder.
You could also see if there are any high speed interfaces available in the CPU which you could leverage - they might be things originally intended for video, for example.
It also appears that you are measuring only a digital signal, ie, probalby one bit. If you want to handle a higher input sample rate than the FPGA fabric can support, that could mean you could potentially use something like a deserializer block at the edge of the FPGA to turn the 1-bit input stream into a slower stream of wider samples to store.
In terms of output, once you have a vector of samples in a buffer it's pretty simple to turn that into a scope/logic analyzer type plot, with as much zooming, cursor annotation, automatic measurement or whatever you like.
Also don't forget that if the intent is only to use this during development, FPGAs and their tools often have the ability to build a logic analyzer right into the design, with the data claimed over the programming interface for plotting on a PC.
I am trying to make a program in SciLab that would make a real time plot from data received from serial port.
My idea is to execute new plot function after every single portion of data received. But I think it is too much work for the computer and SciLab will not work properly and miss data.
Do you know some option to plot real time data from serial COM port? SciLab or another free program?
It is perfectly possible to implement such a hardware setup run from a Scilab session that plots live data.
We do it #ENSIM, for practicals in optics: we move a translation actuator step by step (Scilab driver # https://fileexchange.scilab.org/toolboxes/255000, plugged to port#1), and for each step we read a transmitted signal with an optical powermeter (driver # https://fileexchange.scilab.org/toolboxes/223000, plugged to port#2). The refresh frequency of the powermeter is 1-2 Hz. So no problem to get a live plot of received data.
As well, we have written a Scilab driver for the very popular M38XR multimeter (# https://fileexchange.scilab.org/toolboxes/232000). A syntax is implemented to continuously display the live data coming from the multimeter (same low refresh rate ~1Hz).
Etc.
2 new Scilab drivers to come soon for new instruments (a furnace, and another popular multimeter). All our drivers presently on FileExchange will be updated for Scilab 6 and gathered in a single ATOMS module (then easier to document and maintain).
I've been writing a LabVIEW program to drive 3 axis Newport SMC-100 stepper motor controller for horizontal, vertical and rotational movement. I've implemented a for loop that repeatedly perform .3 degree turn followed by 5 separate horizontal movement until it turns a full circle. The program always fails at tellcontrollerstatus.vi, and gives me VISA 1073807339 timeout error. When I restart the program, it'll tell me there is no RS-232 connection available. The weird thing is, it happens at various loop iteration.
I'm sure the COM port setting is correct. If it's a simple program that tells the rotational stage to make a full turn in 1000 steps, it doesn't have any problem. It's only when I try to control two axes in each loop that I have problem.
I tried implementing delay using flat sequence but it doesn't really help. Eventually, I gave up changing the program and just tried another USB-RS-232 adapter cable. Then the problem is gone.
Although the problem was solved, it's not based on good diagnostic procedure and seems to be sheer luck. I'd like to know if there is a proper way to diagnose this kind of problem?
I always use addrcom to diagnose port.
http://www.ontrak.net/adrcom.htm
Also, you can short circuit pin 2 with 3 on DB9 and see weather do you receive the same data you have sent over COM. If you do so it means that your USB-RS-232 adapter cable working properly.