-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Arduino Mega doesn't work with Luke Mester’s HP3478 Control #29
Comments
Thank you for your report. Theoretically there shouldn't be any difference, however, I will dig out my Mega and give it a test with Luke's software. Are both boards genuine Arduino boards or clones? |
Hi, thanks for the reply. both are clones, i have dug deeper and looks like
the Mega takes a few hundreds of milliseconds more to boot up than the uno.
I have seen in an EEVblog that Luke's software already uses a delay in the
serial port opening to wait for the arduino to boot up, maybe the delay is
fine for the uno but not the Mega?
By the way, i have write some python scripts to automate instruments and
measures, if you would like to take a look please visit
https://github.com/Minu-IU3IRR/AR488_GPIB_python_control, if you like it
feel free to feature it in ine AR488 repo!
Manuel, IU3IRR
Il giorno mer 27 lug 2022 alle ore 22:45 Twilight-Logic <
***@***.***> ha scritto:
… Thank you for your report. Theoretically there shouln't be any difference,
however, I will dig out my Mega and give it a test with Luke's software.
Are both boards genuine Arduino boards or clones?
—
Reply to this email directly, view it on GitHub
<#29 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/APLVF6QUID3WKSZXINRR5U3VWGNXRANCNFSM54OFDDJQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Manuel, Thank you for the feedback. One of the reasons for asking was to ascertain whether the might a difference in the UART being used. Mega 2560 clones have the same CH340 chip onboard as the Uno so that rules out a different behaviour due to UART hardware. The timing of the delay might be relevant however. I was just in the process writing an e-mail to Luke to ask him whether he has ever tested his program with a Mega so I will forward this information to him and will forward you his reply. Thanks for pointing out the scripts. It is interesting to see other projects being written and designed to work with the AR488. I might see whether I can adapt one of them to work with the HP34401A or perhaps even the Keithley 2000. |
thank you very much, unfortunately i do not have a 34401 or a Kiethley 2000
so i have not written anything.
If you need any help on adapting my script please get in touch, also since
i am still learning I would like to see how someone else modify my work!
Manuel, IU3IRR
Il giorno mer 27 lug 2022 alle ore 23:15 Twilight-Logic <
***@***.***> ha scritto:
… Manuel,
Thank you for the feedback. One of the reasons for asking was to ascertain
whether the might a difference in the UART being used. Mega 2560 clones
have the same CH340 chip onboard as the Uno so that rules out a different
behaviour due to UART hardware. The timing of the delay might be relevant
however.
I was just in the process writing an e-mail to Luke to ask him whether he
has ever tested his program with a Mega so I will forward this information
to him and will forward you his reply.
Thanks for pointing out the scripts. It is interesting to see other
projects being written and designed to work with the AR488. I might see
whether I can adapt one of them to work with the HP34401A or perhaps even
the Keithley 2000.
—
Reply to this email directly, view it on GitHub
<#29 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/APLVF6WUJXNP5WTX4JILL6DVWGRGPANCNFSM54OFDDJQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
I have just received word from Luke Mester that he has added a couple of new settings in his program to allow the length of delays to allow for the Arduino to reboot as well as for a response to a GPIB command to be adjusted. Could you try his latest version and let me know whether it solves the problem? |
I also have some issues with the Mega 2560 in device mode and usage of sn7516x buffers. I‘m not able to send data to the AR wit the NI Visa tool. I tested without the buffers with same issues. With nano board it works fine. Has anybody tested the mega2560 with success? |
Can you elaborate on the issues you are having please? Looks like you have eliminated the 7516x buffers. Which Mega2560 layout are you using please? |
Hi, I did some further Investigations with the SN7516X buffers an switched to a Arduino Uno board now (original). My Mega Boards have also been original Arduino ones, no clones... I have defined a start maco to bring the AR488 in device mode: after programming the mode and adrr is set correct: I'm using NI VISA Interactive control tool to communicate with devices. When I open the tool an do a bus scan the AR488 is not present on the bus, but the AR488 gives some responses on serial port to the bus scan since debug is active: C:\Users\micha\Desktop\AR488-master\AR488-master\src\AR488\AR488_GPIBbus.cpp:869 (setControls) > Set GPIB lines to idle state Since the AR is not present I open the instrument with the resource string in the NI tool manually (GPIB0::20::INSTR). After opening the communication to the AR488 it goes in endless loop: C:\Users\micha\Desktop\AR488-master\AR488-master\src\AR488\AR488_GPIBbus.cpp:549 (receiveData) > After loop flags: I'm able to perfomr a read request in NI Tool and the data will be transfered correct from AR488 to NI Tool: C:\Users\micha\Desktop\AR488-master\AR488-master\src\AR488\AR488_GPIBbus.cpp:869 (setControls) > Set GPIB lines to idle state When I try a write command in NI Visa Tool and send "IDN*?" to the AR 488 I get an error: The AR resonds to the the READ request with the following in debug window: C:\Users\micha\Desktop\AR488-master\AR488-master\src\AR488\AR488_GPIBbus.cpp:869 (setControls) > Set GPIB lines to idle state C:\Users\micha\Desktop\AR488-master\AR488-master\src\AR488\AR488_GPIBbus.cpp:549 (receiveData) > After loop flags: The behavior is the same with Arduino Mega (original Arduinos). I tried two of them and checked cabeling many times. Now I'm using the uno like mentioned at the beginning (DC is connected to Pin 13 and TE to 6) like the example of the manual. When I'm using an arduino nano without buffers the device mode works correct and I can send and read data with the VI tool. It seems there is another general issue during the bus scan. If only a GPIB master and the AR488 are on the bus they AR will not be detected as instrument. If another instrument like multimeter is present on the bus the bus scan shows a lot of instruments which are not really present on the bus. But in this case also the AR488 will be listed and can be opened for communication. I hope this helps you I did some further investigartions today. After deactivation all debug functions (GPIO + Serial) I was abble to write data from my GPIB interface to the AR88 in device mode. It's not working 100% and I still get some errors but I know my cabeling is correct now. The behavior is the same on my und and AVR2560 board. It's working but there are still some NRFD and NDAV errors present. It seems it's a timinig issue |
Hello, just one question concerning interrupts on the mega 2560. Why is the interrupt section for the 2560 default layout in AR488_Layouts.cpp commentet out and not active? USE_INTERRUPTS in config will not activate. /***** Enable interrupts ****/ volatile uint8_t atnPinMem = ATNPREG; void interruptsEn(){ #pragma GCC diagnostic error "-Wmisspelled-isr" // Has PCINT5 fired (ATN asserted)? // Has PCINT4 fired (SRQ asserted)? // Save current state of PORTD register #endif //USE_INTERRUPTS |
The interface no longer depends on interrupts so ENABLE_INTERRUPTS is deprecated and no longer used. Hence it is commented out. The commented out code needs to be removed. Thank you for bringing this to my attention. As regards the errors you are getting, these appear to be GPIB communication errors. It seems you have made some progress though? Enabling debugs does affect timing as it takes CPU time to print the debug message. I have tried to minimise this as best I could but it does have unexpected effects sometimes. I have never used the National Instruments VISA tools as it is commercial and I would have to purchase it and its not cheap. For this reason, I have not done any testing with it. I would be interested in what commands it sends to do a bus scan? I imagine its either a serial or parallel poll but it is strange the way it reports multiple instruments like that. Thank you for taking the time and trouble to report back with your findings. I will dig my Mega 2560 out again and do some tests. |
Hi thx for the input. I ordered a logic analyzer to debug the bus since I'm not really familar with the protocal. What I have figured out today is that the data bits are inverted. High signal is logical zero and the analyzer has to invert the data bits to decode. Seems this is not possible in the software so I have to do by hand and I was able to decode my ASCII characters which I have transefered over the bus. At the beginning of the transfer ATN indicates a transfer and three bytes are send to the devic. Can you explain to me what is the content of these bytes? One of them should contain the address of the device. After ATN start and transfer of the three bytes it goes back to high and the payload is transfered in my example the character 'A' follow by the end character '\n'. I also have use the EOI signal to indicate the end of transfer. Looks good so far and I have understood the principle of the write transfer. I can't show NRFD and NDAC because I'm behind the buffer and the buffer is hard configurated as Listener. I'm using a NI GPIB-USB-HS and a Agilent GPIB Multimeter to analyze the transfer. By the was you can use the NI GPIB_USB-HS china closens which are sold on ebay for about 120 EUR. I never had issues with them and used more than ten in different companys over the years. I want to use the AR488 in our RF instruments to replace the NI NAT7210. NI has replace the controller by a ASIC which is sold for 450EUR now and I'm not willing to pay so much money. I think they want to bury the good old GPIB bus. I have forgotten to mention that a arduino nano without the buffers is working good as device. The only problem is the bus scan and it also shows instruments which are not present on bus. There must be a issue with the buffer switching on DC or TE line when activating them in your software. In any case I like the AR488 project! |
Yes, you are correct. Signals are inverted, so the signal is asserted when pulled low to ground and un-asserted when the signal is high. When the controller wants to send something, it initially asserted ATN then sends commnads. Usually it will first send untalk and unlisten bytes, then a talk or listen address and finally a command byte. Much of it is described here: https://www.hp9845.net/9845/tutorials/hpib/ The buffer control states are set primarily in That screenshot looks a lot like the Saleae Logic software. The LA5106 is supported by Sigrok Pulseview which has a GPIB decoder built in which saves the trouble of decoding by hand. I have only a cheapie $25 LA but had also considered purchasing one of those LA5106/LA5032, or even a Hantek 4032 LA but never got around to it. How are you finding using the LA5016? In the screenshot you posted, it looks like the controller is sending stuff and signaling DAV (data available), but there should be something happening on the NDAC and NRFD lines but for some reason there is no response from the 'device'. A failure to switch the buffer to the appropriate state might be one explanation. |
I have been working through wiring up an Arduino Mega 2560 and believe I have found that in the AR488-manual.pdf there seems to be inconsistencies amongst the wiring diagrams for Arduino Mega 2560 layouts E1 and E2 (page 48), the Arduino Mega 2560 E1/E2 pinout diagram (page 49), and the pinout definitions for layouts E1/E2 specified in AR488_Layouts.h. This may be causing some people to wire up their Mega 2560 incorrectly for layouts E1/E2 when running the current source code. I also noticed in AR488_Layouts.h, line 70, for the default layout DIO1 is defined as "DIO1_PIN_PIN" that I believe should just be "DIO1_PIN". |
Thank you for reporting these problems. DIO1_PIN_PIN should indeed read DIO1_PIN. Looks like I need to go through the layouts and check them. |
i have built the interface with an Arduino Mega board, i can not get a connection with the software because it does not recognize it.
i tried a blank Arduino uno and every thing woks so the issue is limited to the Mega boards. other software works fine.
The text was updated successfully, but these errors were encountered: