Jump to content

GoranP

Members
  • Content Count

    20
  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. I'm using Python API version 2.1.24 and is testing callback_voltages. With the function "BrickHAT.set_voltages_callback_configuration(period, value_has_to_change)" I should be able to set value_has_to_change with True or False. But when I test it, with False or True I still get values every period time. I could change the period and it work's, I have tested for example with different times like 1000, 2000 3000. What do I do wrong ??
  2. OK. I found it in the description on the page, see my earlier link, and therefore I thought it was OK. In any case, that what the function I like to use. Understand, I'll wait until next release. ..
  3. Hello. I'm using your library for Python, version 2.1.23, When I try to use function "set_voltages_callback_configuration", (see link https://www.tinkerforge.com/en/doc/Software/Bricks/HAT_Brick_Python.html#BrickHAT.set_voltages_callback_configuration), then I got an error in my code. When I open your file brick_hat.py, then I see that this is missing... Best regards Göran P
  4. I'm looking at a new project, where I would like to use a RaspberryPi 3B+ together with the HAT Brick. I have also a PiJuice that I would like to have on the same Pi, just to have the battery backup. Before I connect these parts together, are there any known incompability? Even the PiJuice has a RTC, would that be any problem? // Göran
  5. I have this evening made a simple test, just with two switches, one connected as NC, the other one as NO. Funny, when I test like this, then it works perfect, for both inputs, both on rising and falling edge, directly in the beginning, No problem. Anyhow, it means i have something funny in my normal program. I have to investigate more there..
  6. OK. I will do as follows. At my little "machine" I will change the connection of the microswitch from Normal Closed to Normal Open, so it can be "operating". At the weekend or under next week I try to built up an mini-enviroment so I more easy and properly could test my problem, and also better describe what's happens. I will come back with more info. Thanks anyway, so far ... // Göran
  7. So, I have now tested the beta-firmware. The result is "Yes and No" ... Yes When I run my software the first time after power on of the Tinkerforge module stack, it function well with the interrupt for the microswitch, (with the Normal Closed contact). No If I stop my software and run it again, then is it as before, I need to touch the microswitch one time before I active my routin's. Do I, for example, make the stack powerless and disconnect it from USB and then reconnect it, then it works directly the first time I run my software. Another drawback I noticed was, (I downloaded the beta even in my second Digital Input card), for normal open contacts it didn't work well. On these I got the same behavour for a normal open contact as I had for the normal closed contacts. It needed to be tipped twice to get any reaktion, after that it was working more or less as usual.. Summary I have tested these sequences a number of times, to see if I could repeat the problem. And so is it. The patter is the same. Beta and Normal Closed contact - works the first program run. When restarting the program, I need to tip twice to get an interrupt. Sorry for the test result ...
  8. I will test it later on this evening and come back with my results.. Thanks in advance ...
  9. I'm using Industrial Digital In 4 Bricklet, the first hardware version and has made my program in Python. My problem is the interupt functionality. To one of the inputs I have connected a micro switch. Because it act as a limit switch for a stepper motor movement, (the signal is also used for reference settings) I have connected as a Normal Closed. In other word, it means that we have signal at the input in normal case. When switch is actived, then the signal drops. In my progam I have also a row with myInput.set_edge_count_config(0b1111, 2, 50), as I want interupts on both rising and falling signals. Whats happens, (or not happens), in my program is that I don't got any responce on the first falling edge of "switch" input. On the second activation of the switch it works as normal. If I first touch the switch before using the rest of functions in my program, then it works. For the other inputs I use Normal Open switches, they work as normal directly from the beginning of the program. So, for me, it seems that the functions, and maybe the firmware, has a problem to handles signals that "High" at start up. If somebody has a solution for my problem, or could explain what I have missed, please tell me. // Göran
  10. +1 I have an equal need, like to use an encoder for positioning. Of course, there is the Industrial Counter Bricklet, but it not solves the connection to the encoder. // Göran
  11. In my project I have two stepper motors, and controllers. The control program am I doing in Python. It had been very nice to have cam-functions in these modules. With cam-function I mean a programmable functionality that let me set a position. When these position is passed, in one or other direction, it should trigger a callback function that inform me that we have passed this position and if we are more or less than the given position. My questions : - is this something that could be fullfilled without a firmware update? (I have tried to do this with use of callback_all_data, but it seems to load the system to much.. ). - Has somebody an idea how to make it nice, with low computer load and fast execution?
  12. Hello again. It have even better if it also where compatible with Nexa units.
  13. Hello. I agree, the receiving is the missing thing. It has been wonderful when could be used as a transeiver. Today i have to use a module from RFXcom, but i had enjoyed when i could implemented into my other Tinkerforge modules
  14. Hello. That was very interesting news. I had for a while ago almost the same problem. I had two Master Brick's, each with a Ethernet module. Each of them had a separate IP-address. No problems to connect to stack 1 or two, it was running good. But starting both the stack's, with two separate Python programs, impossible. My first idea then was, "I have done some configuration error". Anyhow, there was no time for faultfinding, so i made another solution to solve my problem then. Now I understand why it didn't work ... After I was reading your last reply's, I took out the 2 Ethernet modules I had in my "spare" boxes. When testing both of them with Brick Viewer, both of them where showing the same MAC address as you mentioned, (40:D8:55:02:A0:00), not as printed on the labels. One of these modules was ordered in middle Jan -17, the other one in Febr. -17 // Göran P
  15. Hello. I'm in English, meine Deutsch is nicht so gut""... I'm interested of the price.. //Göran
×
×
  • Create New...